Discussion :

[trobin]

Bonjour,

je bosse dans un boite dont une petite part des activités est de développer une Application de contrôle et de pilotage de ses installations industrielles.
Cette application est quasi unique pour un client, et donc coute chère. Toutefois, ce dernier peut avoir des installations industrielles identiques, et de ce fait, il y a 1 risque de le voir copier l'application pour la passer sur un autre serveur, sans passer par la case "payer l'application".
Nous cherchons donc à protéger notre application via un dongle (ou autre moyen efficace). il existe de nombreuses solutions, mais peu sont fiables si j'en crois ce que je vois sur le net. Ma connaissance en la matière est toutefois très très limitée, et c'est pourquoi j'en appelle aux développeurs ici, qui pourraient me conseiller vers un société offrant une protection robuste.

Merci d'avance
Thierry

[Invité]

Salut,

Pourquoi ne pas tenter un systeme de licences se basant sur l'hardware d'une machine ? Genre une licence accordant tel ou tel privileges pour une duree X seulement sur une machine dont le serial de la mobo est XXXX (ou alors selon le serial du CPU (pas toujours defini il me semble) ou la carte reseau).

[trobin]

Merci pour cette réponse.

Nous utilisons déjà ce type de protection, mais elle pose une contrainte dans la mesure où si le hardware tombe en panne et doit être changé, le programme ne tournera plus sans modification et recompilation des sources.
or, les sites industriels sont parfois situés à des milieux de km de nos bureau, difficile donc de faire cette modif, d'autant que les serveurs ne sont jamais connectés à des réseaux accessibles du net.

Donc, il faut une protection "unique", qui puisse être déplacée d'un serveur à l'autre mais toujours dédiée à une et une seule application.

on m'a récemment parlé de ce système de clé sans pour autant dire si c'est bon, efficace et simple à mettre en place: Sentinel
http://www.safenet-inc.com/products/...dware_keys.asp

d'autres choix ?

Merci
Thierry

[Invité]

Je dois avouer que sans connexion a internet et avec la contrainte liee aux licences basees sur le hardware, je vois difficilement un autre moyen que la clef usb...
Par contre je laisserai a d'autre la parole car je n'y connais strictement rien

[trobin]

merci quand même de ton intérêt

[emmr.rida]

Pour mon dernier logiciel, le système de protection contre piratage est basé sur un fichier de licence crypté (avec code d'activation) qui contient des ressources nécessaires au bon fonctionnement des fonctionnalités avancées. Le fichier de licence contient les informations de la société qui l'a acquis. Un fichier de licence standard est livré avec le CD mais privé des ressources nécessaires pour activer les fonctionnalités avancés.
Si l'un de mes clients donne son fichier de licence à un autre, ce dernier profite des fonctionnalités avancées mais lors de l'impression des reçus, factures, devis, etc. se sont les informations de la société du premier client qui seront imprimés.
Ce système n'est pas protégé contre l'installation multipostes.

[trobin]

Merci emmr.rida de ta réponse.

Ta solution est intéressante mais ne répond malheureusement pas à mon besoin. Les clioents n'ont pas de documents de sortie vers d'autres clients pouvant les faire apparaître comme dans un système de factuiration. Il ets pour moi important qu'une installation ne soit posisble que sur une et une seule machine à la fois.

[geek-59600]

Je vais surement dire une enorme bétise mais un systéme par audiotel ne peut il pas convenir ?

Meme si basée si le HardwareId un algo de key unique par hardwareID fourni par audiotel rentre dans tes contraintes non ?

[trobin]

geek-59600,

je ne connais pas ce système Audiotel, mais si c'est un truc basé sur "un lien vers l'extérieur" c'est impossible.
Les serveurs sont situés dans des zonnes sans accès internet et téléphonique.
Il est donc impératif d'installer un système de protection 'autonome' et unique.

[Mac LAK]

De toutes façons, un dongle est "mauvais" dans le sens où c'est cassable si on s'en donne la peine... Tout dépend du coût du cassage par rapport au prix de l'application !

Une solution bête et méchante peut être simplement d'utiliser une simple clé USB contenant une DLL hard-codée en fonction du matériel, ainsi qu'un "lecteur" d'informations matérielles... En cas de crash, ils vous envoient le fichier de données lu depuis la clé, et en retour vous leur envoyez une DLL adaptée.
Cela ne permet pas de savoir que l'ancien matériel n'est plus utilisé, mais au moins ça limite le nombre de copies "connues". Tu peux améliorer en analysant les informations physiques de la clé afin d'empêcher que n'importe quelle clé soit utilisable, cela limite un peu plus, mais de toutes façons ce ne sera jamais parfait.

Une solution un peu plus poussée, demandant un BE électronique, est de claquer un FPGA + un device USB, et de créer un device de cryptage / codage via ce FPGA : par exemple une suite pseudo-aléatoire et/ou un cryptage de données devant transiter par le FPGA.
L'avantage est que cela ne requiert pas de licence de dongle, et que le schéma de protection n'est pas connu à l'avance. De plus, en émulant un device standard par l'USB, on peut pas mal complexifier l'accès aux données tout en faisant croire à un truc "standard" qui ne paie pas de mine...

Enfin, dernière solution "lourde", mais efficace à 100% côté réplication, c'est d'ajouter une carte ISA / PCI / C-PCI / VME (en fonction du matériel) au système, cette carte contenant le FPGA en question, un pont PCI et trois broutilles de câblage. Un driver simple fait par Windriver suffit amplement... Là aussi, un BE électronique est requis, mais les avantages sont les mêmes que ceux d'une clé hard, en plus d'avoir une réplication réellement très difficile (plus facile de sniffer et rejouer une connexion USB qu'un bus PCI...).

Avec un bon BE hard, protéger un serveur revient à un ou deux hommes-mois, plus le coût du matériel (au tarif "proto", très certainement...). En solution uniquement soft, cela revient à une grosse semaine de dév soft, plus le coût d'une clé USB donnée... A toi de voir, en fonction du prix de l'application et des risques, quel est l'idéal.

Je te rappelle en outre qu'il est tout à fait légal d'envoyer chier le client si jamais tu détectes qu'ils ont eu un problème sur une installation sans licence... Y compris si ça a flambé leur serveur !!!
Le simple fait de risquer une annulation de garantie est souvent une mesure anti-copie très efficace, avec les grands comptes.

[trobin]

Merci Mac LAK pour cette réponse complète et détaillée.

Concrètement, nous n'avons pas de BE électronique, cela va donc être difficilement réalisable pour les solutions matérielles "propres";

Concernant la DLL hard-codée en fonction du matériel sur une clé USB, nous passons déjà par cette solution, même à la seule différence que la protection en question est directement utilisée dans le programme. Or, notre objectif est de pouvoir permettre au client d'être "hardware indépendant" (je parle de hardware fixe, faisait partie du serveur), principalement si le serveur tombe en rade et qu'il prenne un de ses serveurs spare pour faire tourner l'appli. Ne connaissant pas les caractéristiques matérielles de ce serveur spare, cette solution de DLL (ou lib) n'est donc pas viable, car nous ne pouvons pas programmer cette protection pour tous les matériels (connus et inconnus).

Encore une fois, nous devons trouver une solution où l'ensemble de la protection réside dans le dongle et son interaction avec le programme. Dès lors, sans le dongle il ne marchera plus et, si besoin, le programme pourra être installé sur une autre machine, dans la mesure où le dongle y sera lui aussi installé. Bien entendu, le client détiendra un et un seul dongle.

On surfant un peu, j'ai trouvé une liste de sociétés fabriquant et vendant des dongles programmables avec leur propre SDK, le tout intégrable dans une application. La difficulté pour moi est de comprendre leur degré de protection proposé, leur simplicité de mise en oeuvre et de leur fiabilité.

Si quelqu'un connait ou a déjà travaillé avec leurs produits, je serai très intéressé d'obtenir des informations autres que "commerciales", car on le sait bien, chacun va vendre sa solution comme étant LA meilleure.

• Aladdin -- Hardlock, HASP (*)
• Data Encryption Systems Ltd DESkey
• Eutron Electronic Technologies (acquired by Aladdin)
• Feitian Technologies Co., Ltd. (*)
• Matrix Software License Protection System (*)
• Microcomputer Applications, Inc. (MAI) -- KEYLOK
• MicroWorks, Inc. SmartDongle (TM)
• Microcosm Ltd. (*)
• Pace -- iLok
• SafeNet (*)
• SecuTech Solution Inc. -- UniKey
• Senselock Data Security Center
• SG-Lock
• SPYRUS, Inc.
• Syncrosoft/Steinberg
• WIBU-SYSTEMS AG
• MARX Software Security GmbH
• Okyanus Bilisim Teknolojileri
• Data Resolve Technologies -- Software Lock for USB Dongles

* = semble sérieux

Merci,
Thierry

[Mac LAK]

Comme je te l'ai précisé, un dongle, c'est "mauvais" dans le sens où il sera toujours (je dis bien TOUJOURS) possible de le casser... Notamment, c'est "mauvais" parce que l'on sait qu'il y a une protection, et dans 99% des cas, le nom est carrément marqué dessus : cela permet aux hackers de savoir déjà vers quelles pistes s'orienter pour péter la protection.

Le "truc", c'est que tout dépend du rapport entre le coût de craquage (le temps passé dessus) et le coût de l'application... Si tu vends ton appli 20 euros par licence, c'est inutile de vouloir la protéger ainsi, le moindre bout de protection explose déjà le coût de l'application => il est plus rentable d'être "légal".

Si par contre ton application coûte au delà de la centaine de milliers d'euros, cela devient "rentable" de la casser plutôt que d'en acheter une nouvelle version... Il faut donc soit vous protéger par contrat (nullité de garantie, poursuites judiciaires, etc. en cas de piratage), soit par une protection physique. L'idéal, c'est d'utiliser les deux.

Ensuite, un dongle, c'est (en gros) :
- Des fonctions de vérification de la présence du dongle, et de sa "validité",
- Un cryptage de l'exécutable avec pièges anti-debug,
- Une partie matérielle résistante à l'analyse.

Le problème, c'est que si l'application est déjà faite, vous allez devoir rajouter beaucoup de vérifications dans du code "qui marche"... Ce qui va imposer de tout retester. On est alors souvent tentés de rajouter "peu" de protections, ce qui rend parfois l'exécutable craquable en modifiant UN SEUL OCTET dans l'image binaire (risible...). Si l'on en rajoute trop, on grève les performances. De plus, les pièges anti-debug peuvent également poser des soucis aux développeurs eux-mêmes...
La solution n'est donc absolument pas triviale, et possède un coût certain.

Pour ma part, j'aurais tendance à dire que la protection la plus efficace est la moins connue / répandue, car peu de personnes ont déjà travaillé à la casser. Je privilégierais donc, pour ma part, la société qui a le moins de "hit" sur les moteurs de recherche Warez.


Si tu veux un parallèle, sur un forum dont je suis admin, nous étions envahis de bots spammeurs... Les protections "classiques" anti-robot étaient détournées sans aucun problème, c'était une vraie plaie de passer parfois une heure par jour à "nettoyer" leurs spams.
J'ai rajouté une protection totalement débile à l'inscription, qui gêne beaucoup moins un humain qu'un cryptogramme visuel, mais qui est "unique" dans le sens où ce forum est le seul au monde à l'utiliser. Bilan, depuis plusieurs années désormais, AUCUN bot n'a pu réussir à s'inscrire... Alors que je continue à voir régulièrement des forums protégés par des méthodes "connues" se faire envahir si une mise à jour a été oubliée.

[trobin]

Ce que tu dis est très intéressant.

C'est clair que le code qui marche devra être modifié afin d'implanter la protection et de ce fait, va pouvoir introduire des risques de plantages/d'erreurs accrus.
La protection par contrat existe plus ou moins, même si elle est je crois très limitée...
Par contre il est évident que nous ne cherchons pas à rendre inviolable la protection, mais à apporter une contrainte non négligeable dans l'éventuelle volonté de copie de l'application.

Utiliser une approche "maison" dans la protection est intéressante comme tu le souligne, mais demande aussi une compétence particulière, que je n'ai pas...

Mais ta dernière suggestion (protection la moins connue) est aussi un direction a évaluer.

[ram-0000]

A une époque, je travaillait chez un éditeur de logiciel et le soft était lié à la machine par un fichier qui contenait de manière synthétique une description du hardware. C'est pas aussi puissant qu'un dongle mais le concept était le même.

Tout cela pour dire que rien que la gestion de ces fichiers et de ces licences, cela occupait une personne à mi temps (1 centaine de client/licences déployées). On ne pouvait pas envoyer le client balader parce qu'il changeait le PC sur lequel l'appli était déployée, donc il fallait refaire une licence. Il fallait gérer les licence de démo (faut bien que le client puisse tester avant d'acheter).

En conclusion, ne pas sous estimer le temps passer à gérer un système de licence quelconque.

[Mac LAK]

Ce que tu dis est très intéressant.

Merci.

La protection par contrat existe plus ou moins, même si elle est je crois très limitée...

Si le contrat n'est pas d'ores et déjà signé (cas hélas le plus fréquent), il est encore temps de le "durcir" sévèrement... Il est par exemple possible d'inclure dans le contrat une clause de "vérification surprise" dans les locaux du client, sous le couvert d'une "maintenance préventive" ou autre prétexte fumeux.

Par contre il est évident que nous ne cherchons pas à rendre inviolable la protection, mais à apporter une contrainte non négligeable dans l'éventuelle volonté de copie de l'application.

Tu as peut-être une solution alors via une clé USB "normale", ainsi qu'un moyen purement logiciel...

Le truc, bien entendu, c'est évidemment d'empêcher que la copie du contenu de la clé génère un "nouveau" dongle de protection, on est d'accord ?
Or, comme toute unité de stockage de masse, une clé USB possède une "géométrie" qui lui est propre, ainsi que plusieurs informations internes "propres"...
Parmi ces informations, tu peux avoir :
- Le nom du fabricant,
- La taille de l'unité de stockage,
- Son nom de volume logique,
- Son type de partition,
- Des informations propres au type de stockage (USB, SATA, SCSI, etc.).

Il est tout à fait possible, voire carrément rapide, de créer un "analyseur" de clé USB qui récupèrerait ces informations depuis une clé vierge.
Une fois ces informations obtenues, on peut s'en servir pour authentifier la clé elle-même : une DLL présente sur la clé, compilée "en dur" avec les informations attendues, analyse son propre support et compare ces informations avec les informations "en dur" qu'elle possède.
En rajoutant deux ou trois trucs vicieux en plus (ex : flux nommés NTFS, écriture d'un secteur sur la clé en "absolu", etc.), on peut tout à fait créer une empreinte de la clé extrêmement difficile à reproduire... Tout en conservant, bien sûr, la capacité à la créer très facilement en interne, dans ta boîte, à partir de n'importe quelle clé USB du marché.

Je résume :
Clé vierge -> Analyseur -> Fichier de données -> Compilateur -> DLL de protection -> Copie sur clé -> Sur-protection de la clé -> Dongle logiciel.
(En bleu, ce que le client peut analyser, en rouge, ce qui reste interne).

Si le client veut "copier" la clé :
- S'il copie juste la DLL, cela ne marche pas : les clés sont physiquement différentes.
- S'il prend la "même" clé, assigne le même nom de volume, copie la DLL : cela peut échouer pour un simple numéro de version interne, ou même numéro de série.
- S'il ne copie pas les flux nommés, c'est mort aussi.
- S'il ne connait pas LE secteur à copier, et à laisser bien sûr au même endroit, c'est mort. Des secteurs de "brouillage" sont également une bonne idée.

Bref, les chances de réussir à copier la clé sont ridiculement faibles. Il sera plus rapide de tenter de craquer la DLL, ce qui peut s'avérer plutôt coton : dans ce cas de figure, les pires crasses sont à faire au niveau de la DLL, de façon à rendre le code particulièrement immonde à récupérer. "Dotfuscator" est ton ami, notamment, ainsi que les noms de fonction sans signification, ou mieux, avec une signification erronée, genre nommer la fonction d'initialisation "DeleteNode", la fonction d'ajout "KillTask", etc... Un peu de code mort en plus, des fonctions inutiles (mais appelant des fonctions "utiles" avec des paramètres prévus pour tout crasher), et ça devrait être bien crade à déplomber.

Cerise sur le gâteau : en cas d'appel infructueux (mettre un compteur, quand même...), tu flingues un des éléments de protection de la clé avec un avertissement par boite de dialogue => retour SAV.

Enfin, si le dongle est détruit, il te sera toujours possible d'en recréer un avec n'importe quelle clé USB achetée au supermarché du coin, en quelques minutes... Donc, tu assures aussi la disponibilité du produit si nécessaire.

Mais ta dernière suggestion (protection la moins connue) est aussi un direction a évaluer.

La solution ci-dessus fonctionne aussi sur le même principe... Et elle est donc assez fiable.

[ram-0000]

...Il est par exemple possible d'inclure dans le contrat une clause de "vérification surprise" dans les locaux du client, sous le couvert d'une "maintenance préventive" ou autre prétexte fumeux.

Essaye un peu pour voir avec nos amis militaires ...

[Mac LAK]

Essaye un peu pour voir avec nos amis militaires ...

J'ai bien dit "possible", tu noteras, et non pas "certain"...

D'un autre côté, les militaires préfèrent avoir le contrôle total, ils achètent donc en général les sources afin d'être peinards et non pas un système à royalties / licences...

[trobin]

@ ram-0000 :

NaeiKinDus avait déjà suggéré cette solution, mais comme je l'ai déjà indiqué, ce n'est pas possible.

@ Mac LAK :

la protection donc tu parles avec la démarche associée (Clé vierge -> Analyseur -> Fichier de données -> Compilateur -> DLL de protection -> Copie sur clé -> Sur-protection de la clé -> Dongle logiciel.) correspond effectivement à notre besoin.
il ne nous parait pas nécessaire de délocaliser une partie de notre code qui marche au sein de la clé, mais d'avoir une interaction entre notre appli et la clé, via les principes que tu listes.

le point "dur" justement pour moi ici correspond à des aspects purement techniques ; d'où mon poste d'origine qui revoit bien vers la question "quel est le meilleur dongle = quelle est la meilleure solution commerciale existante actuellement." Pourquoi une solution commerciale ? c'est simple, car je ne sais pas faire :
- créer un "analyseur" de clé USB
- la DLL présente sur la clé (avec les caractéristiques que tu décris)
- des trucs vicieux

Je sais, en cherchant sur le net, je vais surement trouver toutes les bonnes réponses à mes bonnes questions, mais au bout de combien de temps et avec quel succès (je ne suis aps un cador de la progra, je l'utilise comme support de travail uniquement pour "intégrer" mes codes de calculs)... bref, une solution "ready-made & easy-to-use" me conviendrait bien

[Mac LAK]

il ne nous parait pas nécessaire de délocaliser une partie de notre code qui marche au sein de la clé, mais d'avoir une interaction entre notre appli et la clé, via les principes que tu listes.

Oh, il suffit de pas grand-chose à délocaliser... Juste UNE fonction clé, noyée dans la masse de la DLL (genre initialisation du process), et/ou quelques routines clés.
L'important, c'est que la DLL devra être chargée en JIT, donc pas avec une LIB d'importation mais bien un couple LoadLibrary / GetProcAddress. Très facile, suffit de poser la question si t'as besoin d'un exemple.

c'est simple, car je ne sais pas faire :
- créer un "analyseur" de clé USB

C'est en fait la somme de plusieurs appels de fonctions plus ou moins bas niveau (de l'appel d'API Win32 "basique" pour le nom de volume à un équivalent IOCTL pour les informations USB). Là, c'est plutôt côté hardware qu'il faudra aller demander, mais c'est également facilement récupérable.

- la DLL présente sur la clé (avec les caractéristiques que tu décris)

La DLL intègre le code d'analyse, des données "en dur", et compare à l'exécution les données lues dynamiquement avec les données statiques compilées dedans.

- des trucs vicieux

Oh, c'est simple : éparpiller les informations (vive le préprocesseur utilisé à outrance), les outils automatiques (Dotfuscator est intégré à Visual Studio 2008 par exemple), les nommages à la barbare (et en dépit du bon sens), etc.
Si t'as du mal à te retrouver dans ton code et qu'à part les constantes "en du", tu n'oses plus toucher à rien de peur de tout exploser, c'est réussi...

Pour tous ces points, t'as un forum sur DVP où poser la question.

bref, une solution "ready-made & easy-to-use" me conviendrait bien

C'est effectivement une autre problématique, qui peut coûter (relativement) cher toutefois. Dans ce cas, je préconise d'utiliser le moins courant (ou le moins cher, au choix), le but n'étant alors pas de rendre l'application incassable, mais juste d'empêcher le pékin moyen de pouvoir l'installer deux fois sans passer au tiroir-caisse.

[10_GOTO_10]

Or, comme toute unité de stockage de masse, une clé USB possède une "géométrie" qui lui est propre, ainsi que plusieurs informations internes "propres"...
Parmi ces informations, tu peux avoir :
- Le nom du fabricant,
- La taille de l'unité de stockage,
- Son nom de volume logique,
- Son type de partition,
- Des informations propres au type de stockage (USB, SATA, SCSI, etc.).

Bof... Il existe des logiciels qui montent un fichier ISO de CDRom comme un périphérique. J'imagine qu'il ne doit pas être bien plus dur de faire pareil avec une clé USB (et si ça se trouve ça existe déjà). A partir de là, et à moins d'utiliser les API bas niveau, rien ne distingue ce périphérique de la vraie clé USB: secteurs cachés, flux nommés, etc, y sont intégralement copiés...

Bref, protection craquée en trente secondes