Discussion :

[norwy]

Bonjour,

Je voudrais implémenter un petit système de protection par clé d'installation et je souhaiterais avoir des informations sur la façon de m'y prendre pour générer mes clés d'installations et les gérer par la suite, les trucs à avoir en tête, à ne pas faire etc...

Je sais qu'en pratique, c'est à soit d'imposer ses propres règles mais lorsque l'on n'y connait rien, il faut bien s'appuyer sur des exemples...

Je voudrais partir sur 2 principes de clés :
- Une version simple composé de plusieurs groupe de chiffres (ex: 000-0000-000-0000)
- Une version un peu plus évolué composé de groupes alphanumériques (ex: 0X0-XX00-00X-00XX)

Quelles règles appliquer pour la génération des clés ?
Comment garantir l'unicité de chacune de mes clés (partons sur 10 000 clés uniques) ?

[Fabllot]

Bonjour !

Quelles règles appliquer pour la génération des clés ?
Comment garantir l'unicité de chacune de mes clés (partons sur 10 000 clés uniques) ?

Je ne suis pas expert en la matière mais l'idée qui me vient serait de trouver une fonction bijective (et inversable) partant de l'ensemble {0, ..., n} (n étant ton nombre de clés souhaitée) et allant vers un nombre représenté par ta clé...
En effet on peut aisement penser que la clé peut se traduire par un nombre écrit en base 36 (10 chiffres + 26 lettres)...
Mais cette méthode a un défaut, si quelqu'un trouve comment générer la clé (ou la fonction inverse), il pourra faire un générateur de clé...
L'unique façon - que je connais - de protéger un logiciel est la méthode "Microsoft", avec une activation du soft par Internet... Toutes les clés étant mémorisée, la 2e demande d'activation d'une même clé est refusée...

Si cela peut t'aider...

[norwy]

Merci pour ta réponse Fabllot.

Je ne souhaite pas implémenter un système de protection à la hauteur de celui de Billou, donc je suis plus tenter par une "simple" génération en base 36.

Pourrais-tu me donner un algorithme pour que je puisse savoir comment partir ?

En gros, j'ai 14 caractères (en base 36 donc). Indépendamment de l'algorithme en lui-même, pour générer les clés, la meilleure façon est de boucler sur l'ensemble des clés possibles et ne sélectionner que celles-qui vérifient l'algorithme de validation ?

[Fabllot]

la meilleure façon est de boucler sur l'ensemble des clés possibles et ne sélectionner que celles-qui vérifient l'algorithme de validation ?

Je ne pense pas... Cela ferait 14 puissance 36 solutions à tester... soit un nombre avec 40 zéros !!! En gros, la clé de 14 caractères est justement là pour les hackers ne puissent pas tester toutes les possibilités (il y en a trop!)

Je n'ai pas d'algorithme "type" (ce n'est pas mon domaine, mais je m'y interesse un peu, parce-que je vais devoir le faire aussi sur mon soft)...
Il faut trouver une fonction bijective et inversable de l'intervalle {0, n} vers un sous-ensemble de {0, k}, n étant le nombre de clés désirées et k le nombre de possibilités (14 puissance 36).
Afin d'être sûr que la fonction soit bijective, il faut sans doute prendre une fonction strictement croissante ou strictement décroissante...

Il doit bien y avoir sur le net des sites qui parlent de cela...

Toutefois, le problème avec ces solutions c'est qu'on ne peut vérifier qu'une clé n'est utilisée qu'une seule et unique fois...

[Jean-Marc.Bourguet]

Tu prends un système de cryptage à clé publique.

Ta clé est alors un message du genre type de license puis numéro de série encodé avec la clé privée.

Vérifier la clé consiste à décoder le message (avec la clé publique, donc avoir le soft n'aide pas à forger des clés) et à vérifier que le message est correctement formé.

[sidahmed]

Bonjour,

si tu cherches une fonction bijective qui tend vers l'aléatoire, consulte la bijection aléatoire de Feistel.

Bon courage.

[norwy]

Suite et fin de la génération des clés

J'ai adopté une technique que je crois simple. je vous présente donc les concepts appliqués...

J'ai décomposé mon code de 14 caractères en 2 groupes :
- ce que j'appelle le code de série (numéro d'ordre de la clé généré par un boucle)
- la séquence générée par le code de série

Pour éviter d'avoir un code de série simplissime, je lui ai ajouté des conditions (aucun des caractères du code de série ne doivent être les mêmes).

Pour générer les caractères de l'autre séquence, je fais appel à des opérations basiques à partir des valeur des caractères du code de série :

Exemple de type clé :
XXXXX-XXXXXXXXX (le 1er groupe est le code de série)

Pour le premier caractère de la séquence, on peut faire quelque chose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
valeur1 = (valeur_1er_caractere_code_serie + valeur_2eme_caractere_code_serie + 4*valeur_4eme_caractere_code_serie)%36
valeur2 = (valeur_3eme_caractere_code_serie + 12*valeur_5eme_caractere_code_serie)%36
valeur3 = ...
etc.

36 étant ici la valeur de la base de numération dans laquelle on est (= nombre total de caractères différents utilisés) soit 10 chiffres et 26 lettres.

Pour courroner/complexifier le tout, on peut changer l'ordre et la place des caractères du code de série, rajouter des variables d'écart entre les différentes valeurs et position, du moment que la fonction de validation de la clé prennent compte de tout ça pour ses vérifications.

Note : cela pourrait être XXXXXXXXXXXXXX mais je veux ici représenter la séparation des 2 séquences.

Remarque 1 : Pour l'implémentation, mon code est en C/C++ donc il faut jouer avec les valeurs ANSI (sauter jusqu'à la valeur 65 = 'A' pour atteindre les lettres après les chiffres, etc.)

Remarque 2 : Pour parler chiffres, le code de génération n'a pas de beaucoup de caractères puis que l'on est en base 36. 3 chiffres puissance 36 avec des contraintes entre eux ("non-égalité", "nombre non premier si nombre précédent est premier", etc.) c'est déjà suffisant pour générer pas mal de clés (de l'ordre de 1.5 * 10^18 max) et plus les contraintes sont pertinentes, plus la probabilité de trouver un code de série bon multiplié par la probabilité de trouver la séquence qui va avec devient énorme.
Cela associé à de fortes contraintes de saisie du code (fermeture du programme au bout de x échecs, etc.) pour éviter les boucles.

Que pensez-vous de cette méthode ? J'espère avoir été clair dans mon explication.
Pour ma part, je me suis un peu amusé à complexifier les choses à partir de tout ça et je suis assez content du résultat...

Ce qui serait intéressant, ce serait de savoir quels sont les techniques utilisées par les hackers pour arriver à faire un keygen (et donc foutre en l'air tout ce joli travail ) afin d'ajouter d'autres contraintes (dans le code et dans la saisie du code).

Enfin, j'attend vos remarques

[pseudocode]

Ce qui serait intéressant, ce serait de savoir quels sont les techniques utilisées par les hackers pour arriver à faire un keygen (et donc foutre en l'air tout ce joli travail )

Si je devais faire un keygen, je désassemblerai l'exécutable (softIce) et je chercherai la fonction qui teste la validité de la clé. Ensuite j'écrirai le code C équivalent aux instructions assembleurs.

Après, soit je chercherai l'algo inverse, soit j'utiliserai la "force brute" en testant itérativement des clés jusqu'à en avoir une valide.

Bien sur, tout cela au conditionnel...

[norwy]

En gros quel que soit la complexité de mon algo, ma protection ne peut être efficace qu'avec des moyens de vérification redondant tels que l'enregistrement/vérification en ligne et autre (=technique de billou).

Ben au moins je suis fixé... merci pour ta "pseudo-réponse" pseudocode

[pseudocode]

En gros quel que soit la complexité de mon algo, ma protection ne peut être efficace qu'avec des moyens de vérification redondant tels que l'enregistrement/vérification en ligne et autre (=technique de billou).

Pour lutter contre le keygen il suffit que la clé soit dépendante du système, par exemple en y ajoutant des informations issues du hardware (adresse mac, id unique du processeur, ...). C'est la technique de "billou" pour eviter qu'une meme clé de XP soit utilisée sur tous les PC.

Contre cette technique, les hackers ont deux choix:
- Fausser les informations issue du hardware (virtualisation, hook, ... )
- Modifier/Supprimer le programme de vérification (patch)

toujours au conditionnel...

[norwy]

Effectivement c'est bon à savoir.... Je vais voir comment les choses évoluent de mon côté mais je garde cette dernière suggestion sous le coude.

[paradize3]

Bonjour,

Pour lutter contre le keygen il suffit que la clé soit dépendante du système, par exemple en y ajoutant des informations issues du hardware (adresse mac, id unique du processeur, ...). C'est la technique de "billou" pour eviter qu'une meme clé de XP soit utilisée sur tous les PC.

Donc ca n''est pas pour lutter contre les keygens mais pour eviter que la meme clee se repende partout sur le net

Pour lutter contre les keygen (comme je crois qu'il a ete mentionne), tu peux utiliser des fonctions cryptographiques, ainsi ton programme peut verifier qu'une clee est valide, mais tu peux etre confiant qu'un hacker qui analyse ton programme ne pourra pas savoir comment generer des cles valides (ne dispose pas de la clee privee en gros). Dans ce contexte, la cryptographie sur courbes elliptiques est souvent utilisee.

les autres commentaires de pseudo-code restent valides, en particulier -quoi que tu fasses- tu ne pourras pas empecher un hackeur de patcher ton programme pour qu'il accepte une clee bidon.

Salutations,

Gregoire

[pseudocode]

Donc ca n''est pas pour lutter contre les keygens mais pour eviter que la meme clee se repende partout sur le net

Les 2 mon capitaine. L'idée c'est d'avoir un couple (clé,code d'activation)

- la clé est spécifique a l'installation (id utilisateur + empreinte hardware)
- le code d'activation est spécifique à la clé (donné par l'editeur)

A chaque démarage le programme regenère la clé (qui est donc la meme tant qu'on ne change pas de hardware) et la confronte au code d'activation via une fonction cryptographique (par exemple: if crypt(clé,secretsalt)==code then true else false).

Ca permet de lutter contre la proliferation des clés (car une partie de la clé dépend du hardware) et contre les keygen (car le code d'activation dépend de la clé qui dépend du hardware).

[paradize3]

Les 2 mon capitaine. L'idée c'est d'avoir un couple (clé,code d'activation)

- la clé est spécifique a l'installation (id utilisateur + empreinte hardware)
- le code d'activation est spécifique à la clé (donné par l'editeur)

A chaque démarage le programme regenère la clé (qui est donc la meme tant qu'on ne change pas de hardware) et la confronte au code d'activation via une fonction cryptographique (par exemple: if crypt(clé,secretsalt)==code then true else false).

Ca permet de lutter contre la proliferation des clés (car une partie de la clé dépend du hardware) et contre les keygen (car le code d'activation dépend de la clé qui dépend du hardware).

Ne melangeons pas tout...
1. La cryptographie peut rendre impossible la création de keygens.
2. L'utilisation d'info hardware /identenfication user, etc. protecte de la prolifération des clées.
3. Aucun des deux ne protège de patches

il est bien sur recommandé d'utiliser 1 et 2 ensemble.

Meilleures salutations,

Gregoire

[pseudocode]

Ne melangeons pas tout...
1. La cryptographie peut rendre impossible la création de keygens.
2. L'utilisation d'info hardware /identenfication user, etc. protecte de la prolifération des clées.
3. Aucun des deux ne protège de patches

il est bien sur recommandé d'utiliser 1 et 2 ensemble.

Tout a fait.

[|PaRa-BoL]

C'est donc là qu'intervient les techniques d' "anti Reverse Engineering" comme par exemple les Obfuscators et autre moyen de "salir" le code pour le rendre plus difficile à comprendre en assembleur.

[norwy]

Mon éxécutable sera pour proco ARM donc si je comprend bien, le hacker devra trouver les outils adaptés au "dessosage" en règle de mon exe... Ou les fabriquer, mais en tout cas, il ne pourra pas s'appuyer sur des programmes existants.

J'ai bon ?

[paradize3]

Mon éxécutable sera pour proco ARM donc si je comprend bien, le hacker devra trouver les outils adaptés au "dessosage" en règle de mon exe... Ou les fabriquer, mais en tout cas, il ne pourra pas s'appuyer sur des programmes existants.

J'ai bon ?

IDA pro supporte ARM, donc bonne chance Je crois que la bonne approche, c'est de passer un temps raisonnable a proteger ton programme, pour qu'il ne soit pas copiable par l'utilisateur lambda tout en restant conscient des limites discutees. (en gros rien ne pourra empecher un hackeur doue et qui a du temps de patcher le programme).

Salutations,

Gregoire

[sorour]

bonjour, j'essaye d'imlémenter la sécurité cryptographique du code mobile, en utilisant le langage de programmation java, je souhaite bien de m'aide, merci