Discussion :

[Gold.strike]

Bonjour,

Nous avons développé une application en WPF. Nous souhaiterions mettre en place un système de licence afin de pouvoir la vendre, de manière individuelle (un particulier récupère l'application sur internet), ou par lot (un certain nombre de licences vendus à une association).

J'ai parcouru un bon nombre de topics dédiés à ce sujet sur le forum, qui m'ont permis d'y voir plus clair :
http://www.developpez.net/forums/d11...el-p-piratage/
http://www.developpez.net/forums/d12...ation-licence/
http://www.developpez.net/forums/d11...eger-logiciel/
http://www.developpez.net/forums/d10...tir-dinternet/
http://www.developpez.net/forums/d11...steme-licence/
http://www.developpez.net/forums/d10...tion-licences/
http://www.developpez.net/forums/d10...t-web-service/

Nous avions d'abord décidé d'utiliser une solution toute faite. Nous sommes parti sur la solution IntelliLock de Eziriz. Mais il semble que la société ait déposée le bilan, car nous n'avons eu aucune réponses aux mails ou au téléphone depuis décembre. Du coup nous utiliserons uniquement la fonctionnalité d'obfuscation de code.

Faute de réponse à nos questions, nous avons alors choisi de développer notre propre solution, afin de pouvoir l'adapter complètement à nos besoins :
- le logiciel en mode "démo" par défaut, avec des fonctionnalités limitées
- la possibilité d'activer le logiciel via l'achat d'une licence valable 1 an
- l'activation doit marcher pour un utilisateur lambda, et pour un utilisateur d'une association

La solution consisterait donc à créer un WebService qui retournerait à l'utilisateur le numéro d'activation, à partir :
- d'un numéro de "série"
- d'un identifiant matériel

A chaque utilisation d'un numéro de série, le nombre d'utilisation sera incrémenté, afin de pouvoir limité le nombre "d'activations" par utilisateur.

Le numéro de série serait fourni :
- à un utilisateur individuel lors de l'achat de licence sur notre site web
- à un utilisateur d'une association, par l'association elle même, pour laquelle nous aurions générée toute une série de numéros

L'identifiant matériel serait quand à lui :
- le hardware ID du disque dur
- ou le numéro de série du processeur
- la solution de l'adresse MAC nous a semblé moins fiable (facilement modifiable, machines virtuelles, ...)

Le WebService retourne un message crypté avec une clé privée, que le logiciel pourra vérifier avec une clé publique.

Mais il reste quelques interrogations :
- ou stocker sur le poste client l'information retournant du WebService (fichier de config, registre)?
- sachant que nous utilisons actuellement un serveur unique pour stocker nos sources, quelques bases clientes pour un autre produit qui n'est pas destiné au "grand public", et un outil de suivi de bugs, serait il préférable de prendre un autre serveur pour héberger ce WebService pour une question de sécurité?
- comment prévoir la possibilité de "déplacer" le serveur hébergeant le WebService, sachant que l'adresse sera probablement stockée en "dur" dans le logiciel?
- quelles sont les informations à stocker dans la BDD sur le serveur? (Je pense conserver les numéros de séries, avec un état, et le nombre d’utilisation. Mais serait il utile de stocker également des infos sur l'utilisateur?)

Avez d'autres remarques sur la solution envisagée?
Ou d'autres conseils nous permettant d'éviter de faire des erreurs?

Merci d'avance,

[Graffito]

ou stocker sur le poste client l'information retournant du WebService (fichier de config, registre)?

Nous utilisons la base de registre ET un fichier pour éviter que l'effacement du fichier ou de la clé réinitialise la période d'essai.
Il faut veiller à choisir des chemins qui ne posent pas (ou peu) de problèmes au niveau des droits utilisateur, comme par exemple :

Code :

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

1
2
3
4
5
string FileDir=Environment.SpecialFolder.ApplicationData ;
...
string RegKey          = "Software\\"+ProviderName+"\\"+ProgramName ;
Microsoft.Win32.RegistryKey TheKey = Microsoft.Win32.Registry.CurrentUser.CreateSubKey(RegKey);
TheKey.SetValue("Content", FileContent);

- comment prévoir la possibilité de "déplacer" le serveur hébergeant le WebService, sachant que l'adresse sera probablement stockée en "dur" dans le logiciel?

Je conseillerai de prévoir une mise à jour automatique du programme.
Si c'est le cas voici comment nous pratiquons : via une httpWebRequest, nous chargeons une page Web (appelons-la P) dont nous extrayons l'identification de la dernière version et l'URL qui contient nouvel exe (sous forme zippée). Evidement, ça ne résoud que partiellement le problème : il faut laisser pendant un certain temps la page Web P ancienne et la nouvelle, le temps necéssaire pour que la mise à jour automatique ait été effectuée chez la grande majorité des utilisateurs. Pour parer à un grave problème d'hébergement, on peut éventuellement créer 2 pages P1 et P2 et faire une httpWebRequest sur P2 si P1 n'est pas trouvée.

quelles sont les informations à stocker dans la BDD sur le serveur? (Je pense conserver les numéros de séries, avec un état, et le nombre d’utilisation. Mais serait il utile de stocker également des infos sur l'utilisateur?)

Nous associons au n° de licence l'info matérielle et aux dates un certain nombre d'info telles que le nom, prénom, société et e-mail.
En ce qui concerne les stat d'utilisation, nous envisageons d'enregistrer en local des statistiques et de les transmettre au serveur, soit lors du renouvellement de la licence (si limitation à un an), soit à chaque mise à jour automatique du logiciel.

Avez d'autres remarques sur la solution envisagée?
Ou d'autres conseils nous permettant d'éviter de faire des erreurs?

Evidement, enregistrer en crypté les données d'activation dans la base de registre et le fichier.
Si il existe un mode complet limité à une période d'essai : tant que la clé d'activation n'est pas fournie, enregistrer la date du dernier lancement pour détecter les éventuels changements de date qui opéreraient des "retour dans le passé".
Hors mécanisme d'activation, le logiciel doit pouvoir fonctionner sans connection Web. A ce sujet une remarque : si on fait de la mise à jour auto et qu'il n'y a pas de web, l'exécution d'une HttpWebRequest est longue. On aura donc intéret à la lancer au début des initialisations et à récupérer le résultat (nouvelle version disponible par exemple) en fin d'initialisations.

[Gold.strike]

Nous utilisons la base de registre ET un fichier pour éviter que l'effacement du fichier ou de la clé réinitialise la période d'essai.

Si il existe un mode complet limité à une période d'essai : tant que la clé d'activation n'est pas fournie, enregistrer la date du dernier lancement pour détecter les éventuels changements de date qui opéreraient des "retour dans le passé".

Mais que se passe t'il si l'utilisateur supprime le fichier et la clé du registre?
Faut il forcer l'application à se fermer?
Il faudrait donc "initialiser" la clé de registre et le fichier à l'installation, et les mettre à jour lorsque l'utilisation entre sa clé de licence?
Et quel est le format de fichier le plus adapté? Un XML contenant les infos cryptées?

Je conseillerai de prévoir une mise à jour automatique du programme.
Si c'est le cas voici comment nous pratiquons : via une httpWebRequest, nous chargeons une page Web (appelons-la P) dont nous extrayons l'identification de la dernière version et l'URL qui contient nouvel exe (sous forme zippée). Evidement, ça ne résoud que partiellement le problème : il faut laisser pendant un certain temps la page Web P ancienne et la nouvelle, le temps necéssaire pour que la mise à jour automatique ait été effectuée chez la grande majorité des utilisateurs. Pour parer à un grave problème d'hébergement, on peut éventuellement créer 2 pages P1 et P2 et faire une httpWebRequest sur P2 si P1 n'est pas trouvée.

Donc l'adresse de la page web est stockée en "dur" dans le code de notre logiciel?
En cas de mise à jour, est-il plus simple :
- de télécharger la dernière version et réinstaller le logiciel à chaque mise à jour?
- faire un système de mise à jour "différentielle" des fichiers?

[Graffito]

Mais que se passe t'il si l'utilisateur supprime le fichier et la clé du registre?

Il retourne en mode "demo" comme s'il venait d'installer le soft.

Faut il forcer l'application à se fermer?

La seule possibilité du soft est alors de demander une clé d'activation ou de se fermer.

Il faudrait donc "initialiser" la clé de registre et le fichier à l'installation, et les mettre à jour lorsque l'utilisation entre sa clé de licence?

Tout à fait, et même à chaque utilisation en mode demo pour éviter qu'une modification de la date PC permette facilement de réactiver le soft.

Et quel est le format de fichier le plus adapté? Un XML contenant les infos cryptées?

Comme les données sont cryptées, il faut enregistrer un simple tableau de byte. Perso, j'enregistre la conversion hexadécimale de ce tableau.

Donc l'adresse de la page web est stockée en "dur" dans le code de notre logiciel?

oui, avec éventuellement l'adresse d'une page de backup située sur un autre site.

En cas de mise à jour, est-il plus simple :
- de télécharger la dernière version et réinstaller le logiciel à chaque mise à jour?
- faire un système de mise à jour "différentielle" des fichiers?

La technique que nous utilisons comporte 2 étapes:
1) mise à jour de l'exe seulement,
2) l'exe vérifie systématiquement si il y a une mise à jour différentielle de fichiers à exécuter et opère les download (et suppressions éventuelles) de fichiers.

[Gold.strike]

Comme les données sont cryptées, il faut enregistrer un simple tableau de byte. Perso, j'enregistre la conversion hexadécimale de ce tableau.

Mais dans quel type de fichier enregistrez vous ce tableau de byte? Un fichier XML, un fichier INI, ...?

J'ai également lu un exemple assez complet sur la mise en place d'un système de licence, qui m'amène à me poser plusieurs questions :
http://www.codeproject.com/Articles/...lications-a-Tu

Génération des clés de licence et des clés d'activation

Pour la génération des clés de licence/d'activation, l'auteur recommande d'utiliser un soft dédié : SoftActivate Licensing SDK, qui va se charger de générer des clés de licence signées numériquement en utilisant la cryptographie ECC (Eliptic Curve Cryptography). Ce soft fournit également un support d'activation du produit, la génération d’ID matériel résistant aux remplacements de composants matériels et comprend un serveur de licences.
http://www.softactivate.com/

Qu'en pensez vous? Est il judicieux de "déléguer" cette étape d'un point de vue "économique" (temps de développement, cout de la licence)?

Fusion des assemblies au sein de l'exécutable de l'application

Dans ce même exemple, l'auteur recommande également de fusionner des assemblies « sensibles » dans votre exécutable principal, en préparation de l’obfuscation de code. Il recommande d'utiliser IL Merge pour cela.

Cette étape est-elle vraiment indispensable?

Obfusaction du code

Pour l'obfuscation du code, il recommande de cumuler 2 outils :
- les capacités d'obfuscation du code de contrôle de flux de Eazfuscator (en désactivant le changement de nom et de cryptage de chaîne)
- Obfuscar pour gérer le renommage et le cryptage de chaîne.

De votre coté, trouvez vous qu'il est vraiment nécessaire d'utiliser différents outils, ou un seul peut il être suffisant?

Utiliser des noms forts pour les assemblies

Enfin, il recommande d'utiliser un "nommage fort" pour les assemblies.

Encore une fois, cette étape apporte t'elle un vrai "plus"?

Serveur hébergeant le WebService

Nous utilisons actuellement un seul serveur pour héberger :
- nos sources
- les bases de données clientes (actuellement : 3 entreprises comptant très peu d'utilisateurs, donc peu de risques de "piratage")
- un MANTIS
- d'autres WebServices utilisées par une autre application développée pour nos clients actuels

Du point de vue de la sécurité, la nouvelle application étant plus orientée "grand public", n'est il pas risqué d'héberger le WebService sur le même serveur?

Merci d'avance pour vos retours,