Question

J'implémente une petite application en C que je souhaiterais vendre ultérieurement en tant que shareware à un prix raisonnable. Il commencera par un essai de 30 jours, dont je suis déjà tout à fait sûr de la mise en oeuvre.

Le problème que j’ai cependant, c’est que je ne sais pas trop comment implémenter la vérification de la clé de produit. Ce que je pense, c’est que le client peut s’inscrire sur ma page Web (après avoir essayé le produit pendant un certain temps), payer pour le produit et obtenir une clé de produit sous la forme aaaaa-bbbbb-ccccc-dddddd-eeeee via e -mail (ou peut-être disponible via son profil sur mon site). Pas de problème jusqu'à présent. Il ou elle dépose ensuite la clé dans les champs de clé appropriés de mon application et la l'application est enregistrée.

D'après ce que j'ai pu comprendre jusqu'à présent, les gens recommandent AES ou RSA pour cela. Pour être honnête, j'ai pris une autre direction au collège (pas de cryptographie) et le cours de cryptographie que j'ai suivi était il y a quelque temps. Mais de ce que je me souviens, AES est un algorithme de chiffrement symétrique, ce qui voudrait dire que je n’aurais qu’une clé pour le chiffrement et le déchiffrement, non? Comment puis-je alors générer des milliers de clés de produit et toujours les valider dans mon application (qui, en passant, ne nécessiteront pas d'accès à Internet ..., donc pas de vérification avec un serveur)?

Donc je suppose que la RSA serait la voie à suivre? Mais RSA ne produit-il pas de longues clés (au moins plus que les 25 caractères requis en haut)?

Dans un autre fil J'ai lu que certains produits n'utilisent même pas le chiffrement pour la génération / la vérification de la clé de produit, mais utilisent simplement des contrôles tels que "ajouter le 2. et le 17. caractère et qui devraient totaliser à x".

Quel est le moyen le plus rapide, le plus simple et le plus sûr d’y aller? :-) Les échantillons de code seraient du sucre!

Cordialement,

Sébastien

PS: Oh ... et s'il vous plait, ne me dites pas comment ma clé peut et sera fendue à un moment donné ..... je suis au courant, c'est pourquoi je ne veux surtout pas dépenser beaucoup de temps avec cette question, mais en même temps ne le rend pas trop facile pour le cracker occasionnel.

Était-ce utile?

La solution

Les algorithmes symétriques sont limités en ce que tout pirate novice avec un désassembleur peut trouver votre clé (ou l'algorithme utilisé pour en générer une) et créer un "keygen".

Pour cette raison, la cryptologie asymétrique est la voie à suivre. Le principe de base est quelque chose comme ceci:

  • Lorsque l'utilisateur vous achète une licence, vous collectez certaines informations d'identification sur l'utilisateur et / ou son environnement (il s'agit généralement d'un nom complet; parfois aussi d'une entreprise).
  • Vous créez un hachage MD5 128 bits avec ces informations.
  • À l'aide d'une courbe elliptique cryptée, chiffrez ce hachage à l'aide de la clé privée sur le serveur.
  • Le texte chiffré sur 128 bits peut être représenté à l'utilisateur sous la forme d'une chaîne de 25 caractères composée de lettres et de chiffres (plus des tirets séparateurs pour la lisibilité). Notez que 26 lettres + 10 chiffres = 36 valeurs discrètes et que 36 ^ 25 > 2 ^ 128.
  • L'utilisateur tape cette clé de produit dans votre boîte de dialogue d'enregistrement. Le logiciel client le reconvertit en un nombre de 128 bits (16 octets), le déchiffre à l'aide de la clé publique de votre crypto EC et compare le résultat à un hachage MD5 des informations personnelles de l'utilisateur, qui doit correspondre à ce qui a été utilisé pour l'enregistrement. .

Ceci n’est bien sûr que l’idée de base. Pour plus de détails et le code source, voir Clés de produit basées sur la cryptographie à courbe elliptique .

Autres conseils

La vie est plus simple si vous achetez simplement une solution.

http://www.kagi.com/kagisolutions/index.php

Kagi vous permet de collecter des paiements et vous aide à gérer les clés.

Un gars a écrit sur son blog sur la manière dont il a traité la question des numéros d’enregistrement. Une de ses entrées de blog est Génération de numéros d'enregistrement uniques .

Oui, RSA et AES sont deux choses très différentes:

  • RSA est une cryptographie à clé publique, impliquant une clé publique et une clé privée, et est assez lente. L’utilisation principale consiste à mettre en place un échange sécurisé d’une clé de session à chiffrement symétrique.
  • AES est un cryptage symétrique rapide et sécurisé.

Étant donné que votre application ne communique pas via des canaux publics et que l'utilisation de la cryptographie est limitée à l'activation / l'enregistrement du produit, vous souhaiterez utiliser un chiffrement symétrique. Les avantages des chiffrements à clé publique résident dans la gestion des clés, que vous allez gérer sur votre site Web ou par courrier électronique.

Notez qu'il n'est pas nécessaire de distribuer la même clé pour chaque client. Vous pouvez générer un hachage de certaines informations d'enregistrement et le XOR avec quelque chose d'autre (une clé de session fixe, peut-être). Envoyez cela au client, et le programme pourrait générer le même hachage et XOR sera la clé que vous avez envoyée pour produire la clé fixe d'origine.

Traiter avec la cryptographie n’est pas une chose à faire à la légère. Comme vous le mentionnez, vous vous attendez à ce que cela soit fissuré. Si vous faites vous-même, cela arrivera presque certainement. Vous pouvez toujours utiliser votre propre implémentation pour "garder les gens honnêtes honnêtes". mais sachez que c'est tout ce que vous aurez. Si vous avez besoin de quelque chose de plus fort, vous devriez acheter une solution après avoir effectué une recherche approfondie sur les solutions.

Vous pouvez consulter cet projet de code . Il décrit une implémentation d'une clé logicielle basée sur l'adresse MAC de la machine sur laquelle le logiciel est exécuté. La méthode n’est pas idéale, reconnaît l’auteur lui-même, et elle diffère un peu de ce que vous recherchez, mais elle peut peut-être vous aider.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top