Description du problème

Faisons quelques hypothèses. Le logiciel est divisé en composants fonctionnels. Les licences concernent les composants fonctionnels de ce progiciel. Les licences peuvent être basées sur le temps, sur la version ou sur un certain nombre d'utilisations, c'est-à-dire que vous pouvez utiliser la fonctionnalité jusqu'à un point défini dans le temps, vous pouvez la fonctionnalité de la version que vous avez achetée ou un dérivé mineur de celle-ci ou vous pouvez l'utiliser un nombre de fois. Il y a deux scénarios principaux que vous devez résoudre, où un attaquant n'a pas accès à une licence et où il le fait.

Attaquant sans licence

Le premier scénario est celui où votre attaquant n'a pas accès à une licence valide pour votre produit. Ce problème est facile à résoudre. Attribuez simplement une clé de chiffrement distincte à chacune des parties fonctionnelles sous licence de votre logiciel. Cryptez chaque partie fonctionnelle avec la clé de cryptage conçue pour cette partie. Vous pouvez désormais distribuer votre logiciel sans vous soucier que quelqu'un puisse déchiffrer des fonctions pour lesquelles il n'a pas de licence puisque vous ne lui envoyez jamais la clé.

Attaquant ayant accès à la licence

Le deuxième scénario, qui est beaucoup plus difficile à résoudre, est celui où votre attaquant a une licence valide pour votre logiciel mais qu'il veut soit redistribuer les fonctions qu'il a concédées sous licence, soit prolonger sa durée de licence.

Maintenant, vous avez besoin d'une source horaire fiable, cela peut être résolu en:

• en intégrant une clé publique dans un dongle et en faisant en sorte que le dongle émette un défi aléatoire qui doit être transmis à un serveur de temps. Le serveur de temps répond en signant l'heure actuelle et le défi et en le renvoyant au client qui l'envoie ensuite à la clé et à la clé puis met à jour son horloge interne et se déverrouille.
• mise à jour de l'horloge interne en fonction de la fois qu'il a été branché sur l'ordinateur. Le port USB alimente en permanence votre clé électronique lorsqu'elle est branchée.
• mise à jour de l'horloge interne en fonction des horodatages envoyés par les pilotes installés sur la machine à laquelle il est connecté. Autorisez uniquement les horodatages dans le temps. N'autorisez le recul dans le temps que si la source de temps est un serveur de temps de confiance distant fournissant un horodatage signé.

Si votre licence est basée sur des versions auxquelles vous avez effectivement attaqué et qui n'a pas accès une licence parce que votre fonction de dérivation de clé pour l'unité fonctionnelle prend à la fois l'identifiant de l'unité fonctionnelle et sa version en entrée.

Distribution de clé

Ainsi, une fois que vous avez des clés distinctes pour chaque unité fonctionnelle, vos licences deviennent essentiellement une question de distribution de clés symétriques afin qu'elles puissent être envoyées au dongle. Cela se fait généralement en incorporant une clé symétrique secrète dans le dongle, en chiffrant les clés de déchiffrement de licence avec la clé secrète partagée, puis en signant les fichiers de mise à jour de clé chiffrée. Les fichiers de mise à jour signés sont ensuite transmis au dongle qui valide la signature lors de la mise à jour, décrypte les nouvelles clés avec la clé symétrique partagée et les stocke pour une utilisation ultérieure.

Stockage des clés

Tous les dongles doivent avoir accès à un stockage sécurisé afin de stocker les clés de décryptage de licence, les horodatages d'expiration, etc. En général, cela n'est pas implémenté sur la mémoire flash externe ou EEPROM. Si c'est le cas, il doit être chiffré avec une clé interne à l'ASIC ou au FPGA et signé de manière à ne pas pouvoir être modifié.

Trou de texte brut

Une fois que l'utilisateur a une licence pour votre composant fonctionnel, même s'il ne peut pas extraire votre clé secrète, il peut utiliser votre clé pour décrypter ce composant fonctionnel. Cela conduit au problème qu'il peut extraire tout votre texte brut et remplacer l'appel de décryptage par un appel direct au texte brut extrait. Certains dongles couvrent ce problème en intégrant un processeur dans le dongle. Le composant fonctionnel est ensuite envoyé chiffré au dongle qui déchiffre le composant et l'exécute en interne. Cela signifie que le dongle devient essentiellement une boîte noire et que les composants fonctionnels envoyés au dongle doivent être testés individuellement pour découvrir leurs propriétés.

Oracles

De nombreux dongles sont des oracles de cryptage et de décryptage, ce qui entraîne des problèmes potentiels avec les attaques Chosen-ciphertext, par exemple les récentes attaques d'oracle de remplissage.

Attaques de canaux secondaires

Outre les problèmes d'oracle, vous avez également beaucoup de soucis avec toutes les attaques de canaux secondaires bien connues jusqu'à présent. Vous devez également vous préoccuper de tout canal secondaire potentiel mais non découvert.

Décapsulation

Sachez qu'il existe un certain nombre d'entreprises dans le monde qui se spécialisent dans la sélection et l'audit des puces sécurisées. Certaines des entreprises les plus connues sont probablement Chris Tarnovsky de flylogic, qui fait maintenant partie de IOActive et de chipworks. Ce type d'attaque est coûteux mais peut constituer une menace réelle en fonction de la valeur de votre cible. Cela me surprendrait si quelques dongles, peut-être aucun, sont capables de résister à ce type d'attaquant à gros budget.

Fonctionnent-ils

Étant donné un dongle basé sur un cryptage fort, n'est pas basé sur le temps puisque vous ne pouvez pas expirer les clés de cryptage en fonction du temps ni le temps n'est absolu, libre de toute attaque de canal latéral et exécute le code sur la puce, oui, il rendra la découverte du code sous-jacent équivalent à sonder une boîte noire. La plupart des ruptures qui se produisent avec ces dongles sont basées sur des faiblesses d'implémentation par les détenteurs de licences du système de licences matérielles, car l'implémenteur n'est pas familier avec l'ingénierie inverse et la sécurité informatique en général.

De plus, réalisez que même les logiciels où la majorité de la logique est implémentée sur un serveur faisant face à Internet ont été interrompus simplement en sondant la boîte noire et en déduisant le code côté serveur en fonction des attentes du code client. Préparez-vous toujours à ce que votre candidature soit interrompue et élaborez un plan pour y faire face lorsque cela se produit.

Il est clair que Peter a abordé les principaux points d'une mise en œuvre correcte. Étant donné que j'ai - sans publier les résultats - «craqué» deux systèmes de clé électronique différents dans le passé, j'aimerais également partager mes idées. user276 fait déjà allusion, en partie, à quel est le problème.

De nombreux éditeurs de logiciels pensent acheter une sorte de sécurité pour leur modèle de licence lorsqu'ils octroient une licence à un système de dongle. Ils ne pouvaient pas être plus éloignés de la vérité. Tout ce qu'ils font est d'obtenir les outils qui leur permettent d'implémenter un système relativement sécurisé (dans les limites indiquées dans la réponse de Peters).

Quel est le problème de la protection contre la copie en général? Si un logiciel utilise un cryptage mathématiquement sain pour son programme de licence, cela n'a aucune incidence sur la sécurité de la protection contre la copie en tant que telle. Pourquoi? Eh bien, vous vous retrouvez dans une situation de catch 22. Vous ne faites pas confiance à l'utilisateur (car l'utilisateur pourrait copier le logiciel), vous cryptez donc des éléments ou utilisez le cryptage d'une manière ou d'une autre dans votre schéma de protection contre la copie. Hélas, vous devez avoir votre clé privée dans le produit pour utiliser le cryptage, ce qui contredit complètement la notion de méfiance envers l'utilisateur. Les dongles essaient de mettre la clé privée (et / ou l'algorithme et / ou d'autres ingrédients) dans le matériel de telle sorte que l'utilisateur n'ait aucun accès en premier lieu.

Cependant, comme de nombreux fournisseurs ont l'impression qu'ils achetez la sécurité prête à l'emploi, ils ne font pas d'efforts pour une mise en œuvre correcte. Ce qui m'amène au premier exemple. C'est un programme de CAO que ma mère utilisait. Sachant que les dongles se connectant au LPT ont tendance à échouer plus souvent que leurs homologues USB plus récents, j'ai décidé de "contourner" celui-ci. C'était vers 2005.

Cela ne m'a pas pris trop de temps. En fait, j'ai utilisé une simple attaque de placement de DLL (le nom sous lequel le scénario est devenu connu plus tard) pour injecter mon code. Et ce code n'était pas trop élaboré. Une seule fonction particulière a renvoyé la valeur que le dongle lirait habituellement (numéro de série), et c'était tout. Je passerais le reste des fonctions à la DLL d'origine dont le fournisseur de clé électronique a besoin pour être installé avec le pilote.

L'autre clé était un peu avant cela. Le problème ici était que je travaillais pour un sous-traitant et que nous n'avions un accès limité qu'au logiciel pour lequel nous étions censés développer. C'était vraiment une question de bureaucratie entre la société qui a licencié le logiciel et le fournisseur de logiciels, mais cela nous a causé des problèmes majeurs. Dans ce cas, il était un peu plus difficile de travailler autour du dongle. Tout d'abord, un pilote devait être écrit pour renifler les IRP depuis et vers le périphérique. Ensuite, l'algorithme utilisé pour le cryptage a dû être découvert. Heureusement, tout n'a pas été fait dans le matériel qui nous a fourni le trou de boucle. En fin de compte, nous avions un petit pilote qui se faisait passer pour le dongle. Ses fonctionnalités ont été étendues jusqu'à lire un vrai dongle, enregistrer les données (en fait les transmettre à un programme en mode utilisateur en les sauvegardant), puis le recharger pour se faire passer pour ce dongle.

Conclusion: les dongles , quel que soit leur type, s'ils implémentent les fonctionnalités de base du programme auquel ils appartiennent, seront difficiles à déchiffrer. Pour tout le reste, cela dépend principalement de la détermination et de la volonté de mettre le temps de la ou des personnes qui ont entrepris de contourner le dongle.En tant que tel, je dirais que les dongles posent un obstacle considérable - s'ils sont correctement mis en œuvre - mais négligence de la part du fournisseur de logiciels cherchant à protéger sa création, également une simple huile de serpent.

Tenez compte du tout dernier paragraphe de la réponse de Peters. Mais je voudrais ajouter une autre réflexion. Les logiciels qui valent vraiment la peine d'être protégés, car ils sont uniques en un sens, ne devraient pas être protégés sur la base du harcèlement des clients (== la plupart des systèmes de protection contre la copie). Prenons plutôt l'exemple d'IDA Pro, qui peut certainement être considéré comme un logiciel assez unique. Ils filigrane le logiciel pour être en mesure de retrouver la personne qui a divulgué un paquet particulier. Bien sûr, comme nous l'avons vu avec la fuite d'ESET, cela n'aide pas toujours, mais cela crée une dissuasion. Il est peu probable qu'un groupe de crackers mette la main sur une copie, par exemple.

Comme Peter l'a indiqué, regarder comment le dongle est utilisé pour la sécurité est le point de départ pour identifier les vecteurs d'attaque. Dans la plupart des cas, les développeurs de logiciels implémentant la sécurité du dongle sont le point le plus faible.

Dans le passé, lorsque j'ai testé des logiciels avec des dongles, j'ai utilisé des outils gratuits comme ProcessMonitor et RegShot pour identifier des vulnérabilités simples pour vaincre les implémentations de la sécurité des dongles.

J'ai vu un logiciel qui, au démarrage, vérifie la présence du dongle, puis continue son fonctionnement sans utiliser le dongle jusqu'au redémarrage. Dans ces cas, patcher l'application avec OllyDbg n'est pas si difficile de dire à l'application de fonctionner avec toutes les fonctionnalités tant que le dongle n'est PAS branché sur le système.

J'ai également vu un logiciel qui permet un l'utilisateur doit cliquer sur un bouton du logiciel afin que l'utilisateur n'ait pas à insérer le dongle. Le logiciel a affirmé qu'il s'agissait d'une fonctionnalité supplémentaire comme l'option "Se souvenir de moi". RegShot et ProcessMonitor m'ont montré qu'un fichier est écrit avec des informations et tant que le fichier est présent dans le dossier attendu, je peux exécuter le logiciel sur plusieurs systèmes sans clé.

Juste parce que quelqu'un utilise AES ou les Dongles matériels ou tout XYZ ne signifie pas qu'ils sont sécurisés. Tout ce qui compte, c'est de savoir s'ils mettent en œuvre ces mesures de sécurité de la bonne manière en supposant qu'il y a maintenant des vulnérabilités connues (ou 0 jours) dans la mesure de sécurité.