Question:
L'obscurcissement en vaut-il la peine
user91560
2015-12-02 15:03:53 UTC
view on stackexchange narkive permalink

Il existe de nombreux outils pour obscurcir les applications .NET.

Les gratuits font quelques obscurcissements de base tandis que les commerciaux semblent en promettre plus.

Ma question est la suivante: cela vaut-il la peine d'être utilisé les outils d'obscurcissement commerciaux ? Fournissent-ils une certaine sécurité? Je sais que tout est craquable si quelqu'un le veut mal. Mais je parle de certains attaquants «moyens». Cela vaut-il la peine d'investir de l'argent dans des obfuscators commerciaux?

Si quelqu'un est intéressé, ce que je veux protéger: la logique du programme et / ou les clés (je sais que les clés ne doivent pas être stockées dans l'application, mais je suis limité dans les endroits où Je peux quand même le stocker en raison du contexte)

Note: Certains utilisateurs mentionnent que parfois obfuscator peut introduire des bogues dans le programme de travail. C'est clairement mauvais. Si quelqu'un peut couvrir son expérience sur ce type de comportement serait également utile. Ce comportement est-il différent des obfuscateurs commerciaux et gratuits?

L'obscurcissement rend la tâche plus difficile pour les attaquants, mais il est toujours possible de le casser d'une manière ou d'une autre. Il leur faut juste plus de temps pour le lire.
[La sécurité par l'obscurité] (https://en.wikipedia.org/wiki/Security_through_obscurity) est une mauvaise stratégie et ne crée qu'une illusion de sécurité.
Le principal problème est que nous ne pouvons pas mesurer avec précision l'obscurcissement et ne pouvons donc pas prouver qu'il est sécurisé. Comme le gars au-dessus de moi vient de le mentionner, cela crée une illusion de sécurité, mais en réalité ce n'est pas tout à fait vrai, car on pourrait affirmer que le cryptage est une dissimulation.
Je pense que cela dépend un peu - l'obscurité est une illusion de sécurité, mais dans un scénario où vous avez des contre-mesures actives (IDS / Audit), cela ne sert à rien de leur permettre de trouver facilement ce qu'ils recherchent. Cela ne s'applique pas vraiment aux binaires.
@Arlix Ce n'est pas vrai. Le chiffrement est la sécurité par le secret, tandis que l'obscurité du code est définitivement la sécurité par l'obscurité. Jetez un œil ici: http://security.stackexchange.com/questions/44094/isnt-all-security-through-obscurity
L'obscurcissement équivaut à ne pas laisser d'objets de valeur exposés dans votre voiture, ce n'est peut-être pas une mesure de sécurité complète, mais cela vaut encore la peine de bloquer l'accès occasionnel. La sécurité par le biais d'arguments d'obscurité à ce sujet n'a en fait pas de sens car vous ne pouvez pas sécuriser le code et permettre aux gens de l'exécuter à moins que vous ne possédiez l'ensemble du système. C'est le même problème que le cryptage DVD / Bluray, c'est logiquement fondamentalement impossible.
La plate-forme de confiance @MarkBooth et les saas sont deux exemples de «vous possédez l'ensemble du système». Les deux avec leurs propres inconvénients et TPM loin d'être omniprésent.
Vous posez une question de sécurité sans indiquer de quelle attaque vous vous inquiétez. Quel actif essayez-vous de protéger? Quelles sont les conséquences d'une attaque réussie?
@MarkBooth, cela dépend de votre confiance dans le module matériel TPM, il ne protège pas le code de l'utilisateur si l'utilisateur a le contrôle physique et peut modifier ce matériel.
@EricLippert: J'essaie de cacher la logique de mon programme à l'attaquant et / ou aux clés qui y sont stockées (je suis limité où stocker les clés, les utilisateurs ne peuvent pas interagir avec le programme, donc le stockage des clés est un problème de toute façon, mais la protection de la logique est également un objectif - J'ai quelques mécanismes ad hoc à l'intérieur qui protègent contre la copie de programme, par exemple la lecture d'un fichier de démarrage à partir d'un emplacement spécifique si ce n'est pas là, le programme ne démarre pas)
Vous n'avez pas répondu à la question. Vous avez décrit certains mécanismes de sécurité faibles, ad hoc, de brassage maison, mais vous n'avez pas décrit la ressource que vous protégez réellement ou l'attaque qui vous préoccupe. Dites-vous quoi, je vous attaque, j'ai obtenu vos clés et je connais toute la logique de votre programme. ** Maintenant que dois-je faire? ** Quelle est la chose que vous * réellement * inquiète qu'un attaquant va faire?
Je ne comprends pas non plus pourquoi vous pensez que masquer le code m'empêche d'une manière ou d'une autre de savoir à quels fichiers mon propre système de fichiers accède. Je suis l'administrateur de la machine; J'ai une connaissance précise à 100% de chaque fichier touché.
@MarkBooth mais il protège le code pour l'utilisateur, pas de l'utilisateur
@MarkBooth Je pense que ce n'est que superficiellement parce que l'intégrité du TPM est supposée.
Nous devrions probablement prendre ceci pour [chat] si nous voulons aller plus loin avec @JamesRyan. (Autres commentaires rangés)
Jetez un œil à http://de4dot.com/. Des outils de désobfuscation sont également présents. La plupart du code obscurci peut être restauré automatiquement et seule une RE est nécessaire pour restaurer son aspect antérieur. La question est, que voulez-vous vraiment obscurcir? Si vous voulez vraiment, VRAIMENT cacher les algorithmes à l'utilisateur, faites-les côté serveur.
Onze réponses:
Skyküff
2015-12-02 15:18:04 UTC
view on stackexchange narkive permalink

Le problème avec l'Obfuscation / Protection côté client est que l'attaquant gagnera toujours.Votre code s'exécute sur son PC afin qu'il puisse tout intercepter et tout manipuler à la fin.Dans le cas spécifique de .NET, il peut être judicieux d'appliquer de base obfuscation pour supprimer les noms de fonctions par exemple, mais les outils gratuits sont parfaitement adaptés pour cela.

Pour répondre à votre question un peu plus spécifique: la plupart des obfuscators commerciaux font les mêmes choses que les libres. pour Confuser / ConfuserEx, les deux sont open source et offrent une meilleure protection que la plupart des produits commerciaux.

Exactement, il convient également de noter qu'il existe des désobfuscateurs pour la plupart des obfuscateurs qui sont disponibles, ce qui facilite la désobfuscation (tm) pour certains que pour d'autres. Il ne sert à rien de payer pour un si Confuser offre les mêmes avantages gratuitement.
"l'attaquant gagnera toujours" - si l'attaquant dispose d'un temps et d'un argent illimités, alors oui. Sinon, il s'agit de savoir si tout ce que l'attaquant pourrait gagner vaut plus que l'effort requis ou non.
En tant que développeur, je peux vous dire que l'obfuscation est inutile. Afin d'exécuter le code (spécialement pour des choses comme .NET où j'exécute vraiment du code CLR), les choses doivent être "désobfusquées" pour que le temps d'exécution puisse l'exécuter. Donc tout ce que vous faites est de changer de belles variables comme posts = posts + 1 en quelque chose comme x = x + 1 à la fin. Si vous avez déjà l'habitude de regarder la variable drôle de code d'octet décompilé et les noms de fonction ne vous ralentiront pas. A continué ....
Je la vois toujours comme ceci b-font.jpg À l'extérieur de la remise. Si c'est bon marché et que quelqu'un se sent mieux, alors foncez. Si vous pensez que cela fournit réellement une sécurité réelle, alors ... Alors allez-y à 0 $ et facile à inclure pour les développeurs dans le processus de construction. Plus difficile que ça et ça n'en vaut pas la peine.
L'argent @vsz peut ne pas être important. Quand quelqu'un s'amuse à faire de l'ingénierie inverse, il le fait pendant son temps libre et économise de l'argent qu'un jeu coûterait, l'inversion est son jeu.
Quelle est la taille de votre code? Je suis d'accord que l'obfuscation n'ajoute pas de sécurité, mais amusez-vous à lire des millions de lignes de code obscurci. Et quand vous en aurez terminé, le code aura probablement changé dans le temps
Dan Pantry
2015-12-02 18:29:13 UTC
view on stackexchange narkive permalink

Soyons clairs: l'obfuscation n'est pas là pour être une forme de sécurité sujette à examen. Il tombera dès que quelqu'un essaiera de contourner l'obfuscation et rendra les choses plus difficiles pour l'attaquant.

Le but de l'obscurcissement est de dissuader les attaquants potentiels d'entrer dans le système sans beaucoup d'efforts, ce qui peut les empêcher d'envisager d'attaquer votre système.

Vous devriez vous demander si cela est utile ou non. Si c'est le cas, implémentez bien sûr l'obscurcissement, mais ne l'utilisez pas comme seul niveau de sécurité.

TheHidden
2015-12-02 15:21:21 UTC
view on stackexchange narkive permalink

L'obscurcissement en vaut-il la peine? Oui, bien sûr, cela en vaut la peine. Toute couche supplémentaire qui n'interfère pas avec une autre couche en vaut toujours la peine. Cela dissuadera la personne moyenne et tiendra la majorité des gens, ou serait des enfants de script, à distance ....

Mais

Les outils commerciaux que je dirais ne le sont pas à avancé pourrait en fait entraver votre développement, l'utilisation d'un logiciel sur mesure que j'ai essayé a pris beaucoup de temps pour s'assurer que le code fonctionnait correctement sous cette nouvelle forme car il était essentiellement codé et chiffré en base64.

rappelez-vous ceci en ce qui concerne la sécurité: si votre logiciel ou produit vaut 1 million de dollars, il en coûte 1 million et 1 pour le casser, vous ne pouvez jamais rendre quelque chose d'assez sûr. obscurcir ne le rendra jamais sûr, mais il ne fait pas de mal d'utiliser des outils gratuits.

L'obscurcissement n'est évidemment pas une sécurité de haut niveau, mais je ne publierais jamais de code sans obscurcissement car il peut cacher des informations importantes (les informations importantes que cela peut protéger sont des conventions de dénomination évidentes donnant les objectifs des fonctions et le fonctionnement de votre application , ce n'est qu'un simple moyen de dissuasion et non une solution). Cela en vaut toujours la peine.

Bien que vous payiez pour un outil? Cela ne vaut peut-être pas la peine.

Quelle? C'est faux. Avez-vous déjà essayé de décompiler du code obscurci? L'obfuscation n'aide pas vraiment du tout contre un attaquant moyennement qualifié qui trouvera une vulnérabilité dans votre programme. Vous ne devez jamais mettre d'informations importantes dans un exécutable. Du tout. Et si vous avez une vulnérabilité d'injection SQL, vous serez tellement malmené indépendamment de l'obfuscation. Ne comptez JAMAIS sur l'obscurcissement pour protéger vos informations importantes.
Je suis désolé @MarkHulkalo mais vous avez clairement mal compris donc avant de faire des commentaires, j'apprécierais que vous lisiez deux fois? ou demander avant de me déclarer faux? J'ai clairement dit que ce n'était pas une sorte de sécurité de haut niveau, clairement, même si d'abord si c'était inutile, cette question n'existerait même pas et les entreprises ne feraient pas des milliers de refaire cela. Le fait est que cela ajoute une petite couche de gêne. avez-vous déjà déobfué du code? la plupart des outils changent les noms de classe, de fonction et de variable ainsi que l'encodent pour rendre plus difficile d'obtenir le point du code. J'ai plusieurs fois.
il ne s'agit PAS de protéger son sur le fait que cela coûte plus de temps et de garder l'utilisateur BASIC ou les enfants de script de merde (qui comptent comme un utilisateur de base la moitié du temps) LOIN! Je peux mettre un panneau de ne pas entrer sur une porte, mais c'est la serrure qui vous empêche d'entrer ... mais la plupart du public n'essaiera même pas la porte. obfucation est le signe sur la porte. il n'y a aucune raison de ne pas l'avoir. ce qui est mon point de vue général, j'ai même souligné que cela ne valait pas la peine de payer pour un outil. si cela valait de l'argent, cela vaudrait la sécurité. Bien que me faisant expliquer plus, j'ai marqué votre commentaire comme utile pour moi. Merci
@silverpenguin, votre réponse est quelque peu trompeuse. Tout d'abord, la question était de savoir si les outils d'obfuscation commerciaux offraient un avantage significatif par rapport aux outils gratuits, et votre «Oui, bien sûr» n'est pas soutenu par le reste de votre réponse. Plus important encore, `je ne publierais jamais de code sans obscurcissement car il peut cacher des informations importantes '- cela ne fonctionne pas comme ça, vous ne pouvez pas vous fier à l'obscurcissement cachant des informations ** importantes **. Ainsi, même si cela ne coûte presque rien de l'avoir et fournit probablement de l'aide, ne donnez pas l'impression que cela protège vraiment les informations.
@Cthulhu J'ai pris en compte votre suggestion et j'ai apporté des modifications si vous avez d'autres suggestions, veuillez le dire.
Les deux premières phrases sont fausses. Le simple fait de «ne pas interférer» ne vaut pas automatiquement la peine. Pour en valoir la peine, les avantages doivent être supérieurs au coût (et il y a toujours un coût, même avec un outil gratuit) pour produire une certaine quantité acceptable de valeur dans un niveau de confiance acceptable spécifié. Sinon, le risque seul en fait manifestement * pas * la peine.
@Xander La seule façon dont ce serait vraiment un problème est si vous offrez un support à une application qui est obscurcie ou même votre modèle, si open source alors pourquoi est même discuté? sinon, l'ensemble de la salle des développeurs convient que c'est toujours bénéfique à la fin du développement. dans le cas du support, vous exécuteriez du code côte à côte. dans cette situation, cela coûterait si peu que vous ne pourriez le mesurer qu'en décimal. si vous avez un exemple de coût élevé, je suis ouvert à l’éducation. peut-être que mon anglais est un peu décalé mais je pense que mon point de vue général tient toujours et n'est pas "faux"
Non, ce n'est pas la seule façon dont ce serait vraiment un problème. Et ce n'est pas théorique. J'ai en fait vu l'obscurcissement (en particulier) causer des problèmes avec les applications, mais dans le cas plus général, toute complexité supplémentaire a un coût, et s'il n'y a pas d'avantage quantifiable, cela n'en vaut certainement pas la peine.
@Xander Je ne nie pas que cela peut mal tourner et je ne dis pas que vous vous trompez, une mauvaise programmation peut causer ce problème. si vous utilisez quelque chose qui sort de l'ordinaire. ce qui n'est pas un problème d'obfuscation. vous n'avez pas toujours BESOIN, mais si vous voulez protéger votre logique, une couche supplémentaire devrait être un avantage. ne vous méprenez pas, j'accepte votre opinion comme votre opinion mais loin des faits. tout cela ressemble à une opinion par expérience. moi-même et vous-même. J'ai vu des problèmes que vous décrivez une fois, jamais au niveau professionnel.
Alors que l'obscurcissement du code bien fait combiné à l'anti-débogage peut améliorer la sécurité dans une mesure limitée, tous les _outils_ qui automatisent de telles choses sont presque inutiles.Vous avez besoin d'un humain intelligent pour masquer manuellement le code, ajouter des fonctionnalités anti-débogage, etc.ou comportement non documenté qui pourrait ne pas être émulé dans Bochs).Mais en utilisant un _tool_?Complètement sans valeur.
Ben
2015-12-02 20:51:11 UTC
view on stackexchange narkive permalink

Non. L'obfuscation n'en vaut pas la peine. Si vous obscurcissez vos programmes, ils seront détectés comme des faux positifs par les antivirus tout le temps . Cela vous causera bien plus de maux de tête que quelques pertes de ventes.

La seule exception serait si vous aviez un logiciel extrêmement précieux - mais si vous n’expédiez pas de clé électronique matérielle, votre logiciel ne l’est pas si précieux qu'il a besoin d'être obscurci.

_ "Si vous obscurcissez vos programmes, ils seront détectés comme des faux positifs par les antivirus tout le temps" _ - Cette phrase est totalement fausse à l'OMI. Avez-vous des références sur lesquelles baser vos accusations farouches?
@MattWilko, Ceci est basé sur ma propre expérience de ce qui se passe. Et à juste titre, l'OMI. Je ne laisserais pas un plombier ou un électricien se faufiler dans ma maison en cachant ce qu'il faisait. Le code informatique qui cache ses actions est suspect de la même manière - il a accès à mes données, il devrait donc être ouvert sur ce qu'il fait. Si vous souhaitez garder votre code secret, concevez-le pour qu'il puisse être exécuté de manière hébergée.
Je soupçonne que cela dépend de l'outil d'obscurcissement que vous utilisez par rapport à celui que j'utilise (cela rime avec "chariot a-trembler-genou"). Je ne me souviens que d'un seul exemple de ce qui se passe et nous avons déployé des logiciels sur des centaines de clients avec toutes les combinaisons OS et AV différentes que vous pouvez imaginer. Mon observation est que votre commentaire n'est pas vrai à 100% - il n'est vrai que dans votre expérience d'utilisation de l'outil que vous avez utilisé
Stephan Bijzitter
2015-12-02 22:05:40 UTC
view on stackexchange narkive permalink

Beaucoup de gens ont déjà mentionné que l'obscurcissement ne faisait qu'augmenter le temps pendant lequel la source d'une application peut être régénérée; cela fonctionne comme un moyen de dissuasion.

Cependant, selon les techniques d'obscurcissement, la taille de l'exécutable résultant peut être considérablement réduite. Certains outils d'obscurcissement peuvent même améliorer les performances de votre application en supprimant toutes les instructions qui ne devraient pas être exécutées.

Dans l'ensemble, j'utiliserais toujours un obfuscateur, mais pas à des fins de sécurité.

Optimisation obfusc ...
Jon Raynor
2015-12-02 22:19:26 UTC
view on stackexchange narkive permalink

Obfuscation! = Sécurité

Si vous écrivez des services Web ou un autre code qui s'exécute sur vos serveurs sécurisés, il n'est pas nécessaire de masquer.

Si vous déployez du code côté client, vous souhaiterez peut-être obscurcir pour qu'il soit plus difficile pour quelqu'un de faire de l'ingénierie inverse de votre code afin qu'il ne puisse pas le voler ou s'en attribuer le mérite.

C'est très facile à décompiler. Code net utilisant ILDASM ou un autre outil. Ainsi, les entreprises peuvent obscurcir pour qu'il soit plus difficile pour quelqu'un de regarder sous les couvertures pour acquérir des connaissances sur le système ou même l'exploiter. Mais c'est toujours un code exploitable qui peut être mis dans un environnement de développement, débogué et examiné localement.

Une fois, j'ai eu un patron qui était paranoïaque à propos d'autres sociétés qui volaient la propriété intellectuelle du code source de l'entreprise, alors il a mandaté le camouflage. Une chose avec les obfuscators est qu'il existe des pratiques de codage qui produiront des bogues après que le code soit obscurci, alors soyez conscient de cela.

Cela en vaut-il la peine? Cela dépend de votre point de vue. C'était important pour mon patron. Pour l'équipe de développement, c'était juste un autre rouage dans le processus de construction qui causait parfois des bogues inattendus, donc nous n'y voyions pas beaucoup de valeur. Cela n'apportait certainement plus de sécurité.

Une chose que je mentionnerai également, pour le support et le dépannage, le code obscurci est plus difficile à diagnostiquer. Les journaux que le système produira seront également obscurcis, vous avez donc besoin d'une carte pour prendre les journaux obscurcis et les transformer en noms de contrôle de source d'origine, etc. Donc, il n'est pas possible de regarder les journaux, des étapes supplémentaires sont nécessaires .

Deux points très importants que vous faites: (1) Si j'ai un programme qui fonctionne et que je l'obfusque et que l'obfuscateur ajoute des bogues à mon programme, bien sûr quel est l'intérêt de l'obscurcir? Pouvez-vous nous en dire plus sur l'expérience que vous avez vécue à ce sujet? Quels outils ont introduit des bogues? (2) Mon programme effectue bien sûr la journalisation, vous dites que les journaux ne seront pas lisibles?
@user200312 - Si votre journal génère une trace de pile, ce sera la pile du code obscurci, qui sera impossible à suivre. En règle générale, lorsqu'une exception se produit, on génère la trace de la pile pour faciliter le dépannage et le débogage. Il faudrait prendre cette trace de pile obscurcie et obfusquer DE afin que vous puissiez trouver la classe réelle, la méthode réelle et le numéro de ligne réel où l'exception s'est produite. Habituellement, lorsque l'obscurcissement est terminé, il produira un fichier de carte afin que vous puissiez revenir aux noms d'origine.
C'est mauvais - je dois le tester. En effet, je génère une trace de pile
@user200312 - Nous avons utilisé DotFuscator. C'est un produit décent. Un cas dont je me suis souvenu était qu'un programmeur utilisait la réflexion et avait codé en dur le nom de la classe. Les noms de classe seraient obscurcis, ce qui entraînerait une erreur. Bien sûr, le code fonctionnait bien localement (non masqué). Je pense que le produit a le paramètre d'ignorer certains scénarios que vous pouvez configurer avant d'exécuter l'obscurcissement, mais il y a des causes dont vous devez être conscient.
Je n'utilise pas Reflection. ps recommanderiez-vous DotFuscator?
Bien sûr, c'est un produit décent.
Ensuite, je devrai à nouveau tester ma DLL après l'avoir obscurcie, cela signifie ...
user72066
2015-12-03 03:30:08 UTC
view on stackexchange narkive permalink

Non. L'obfuscation établit simplement un délai variable. Cela peut arrêter les skiddies et ceux qui ne s'en soucient pas assez pour terminer le travail, mais ce n'est pas le vrai problème. S'il y a une faiblesse dans votre programme, il devient une perte de temps d'essayer de le balayer sous le tapis plutôt que de le réparer en premier lieu.

Investir le temps que vous auriez utilisé pour obscurcir correctement votre code trouver et corriger les vulnérabilités fera un meilleur travail pour empêcher les utilisateurs malveillants, qu'ils soient skiddies ou professionnels.

Walid Nawfal Sabihi
2015-12-02 19:56:53 UTC
view on stackexchange narkive permalink

Si vous voulez une protection contre la falsification d'assemblage ou l'accès au code source, alors un obfuscateur commercial ou même gratuit vous sera grandement bénéfique, juste avant d'en utiliser un, regardez autour de vous pour voir s'il y a un désobfuscateur là-bas, qui vous aidera évaluer la «sécurité» d'Obfuscator. Si c'est une version commerciale, cherchez toujours un essai pour la tester avec votre application, j'ai eu quelques obfuscators gâcher l'exécutable, principalement à cause du "code spaghetti" qu'ils produisent et des proxys et tout ça. Et si vous prévoyez d'accéder à l'assembly à partir du code au moment de l'exécution, je ne pense pas que cela fonctionnera bien pour vous. Néanmoins, étant donné qu'il est facile d'extraire le code source intact d'un exécutable .NET, les obfuscators sont un moyen très utile de rendre plus difficile l'accès des attaquants au code source.

N'oubliez pas de ne jamais mettre de données sensibles sur un programme, même si vous l'avez caché! Stockez toujours les données sensibles telles que les informations de base de données, les clés de chiffrement / déchiffrement côté serveur!

Bon point, la chaîne de const privée EncryptionKey = "MySecret" ne sera pas obscurcie.
@JonRaynor En fait, dans certains obfuscateurs, vous pouvez les encoder / crypter, mais ce n'est pas garanti que cela fonctionnera à 100%
Brad Christie
2015-12-02 22:36:37 UTC
view on stackexchange narkive permalink

De mon point de vue, cela n'en vaut pas la peine.

  1. S'ils veulent vraiment voir comment cela fonctionne, ils le feront. Bien sûr, vous pouvez empêcher les "innocents" de renifler, mais quiconque a des motifs et des moyens l'emportera.
  2. Comme quelqu'un l'a souligné, l'obscurcissement a ses propres problèmes de développement (un autre niveau de complexité / rapport d'erreur votre SDLC actuel).
  3. Avec le passage à SoA, tout ce qui est propriétaire / secret commercial doit de toute façon être déplacé en interne. Plus vous pouvez garder la logique sous votre propre contrôle (sur vos serveurs loin du client), plus vous avez l'assurance qu'il ne sera pas copié / volé.
  4. Passez plus de temps à investir dans votre prochaine version et moins sur la protection de ce qui est déjà fait. Vous ne gardez pas les clients en protégeant l'IP actuelle des copieurs, vous les gardez en étant évolutifs.
  5. D'un autre point de vue, regardez les projets open source; ils distribuent facilement leur code source et maintiennent toujours la traction et la reconnaissance / adoption de l'industrie.

C'est à vous, mais juste mon 0,02 $.

keshlam
2015-12-02 22:38:30 UTC
view on stackexchange narkive permalink

Je suis d'accord pour dire qu'en ce qui concerne la sécurité, java obfucation ressemble plus à un verrou qu'à un verrou; cela n'arrêtera pas un attaquant déterminé mais peut décourager les amateurs.

Cela dépend également de l'obfuscateur. Il est certainement possible de réécrire du code de manière à ce qu'il ne puisse pas être décompilé en Java clair, en utilisant des modèles d'instruction / bytecode qui n'ont pas d'équivalent Java. (Vous pourriez même être en mesure de faire une certaine optimisation, bien que la plupart de cela soit stuvf le compilateur JIT fera probablement de toute façon.) Mais encore une fois, si l'attaquant sait comment travailler avec des bytecodes directement au niveau "assembleur", tout fait est de les ralentir et de les faire travailler plus dur.

Et parfois c'est suffisant pour les faire attaquer une cible plus facile.

Mais tant que votre code ne fonctionne pas physiquement encapsulation protégée (sur laquelle je pense qu'IBM a au moins un brevet) - ou s'exécutant ailleurs sur une machine sécurisée, ce qui est effectivement la même chose - vous ne pouvez pas complètement empêcher les gens de le lire.

Mark Booth
2015-12-02 23:33:46 UTC
view on stackexchange narkive permalink

La valeur de l'obscurcissement ou de la protection dépend de plusieurs facteurs.

En vaut-elle la peine?

Lorsque nous cherchons à protéger un logiciel, nous devons d'abord répondre à une nombre de questions:

  1. Quelle est la probabilité que cela se produise?
  2. Quelle est la valeur pour quelqu'un d'autre de votre algorithme et de vos données?
  3. Qu'est-ce le coût pour eux d'acheter une licence pour utiliser votre logiciel?
  4. Quel est le coût pour eux de répliquer votre algorithme et vos données?
  5. Quel est le coût pour eux de l'ingénierie inverse de votre algorithme et données?
  6. Quel est le coût pour vous de la protection de votre algorithme et de vos données?

Si ceux-ci produisent un impératif économique important pour protéger votre algorithme / vos données, vous devrait envisager de le faire. Par exemple, si la valeur du service et le coût pour les clients sont tous deux élevés, mais que le coût de l'ingénierie inverse de votre code est bien inférieur au coût de développement eux-mêmes, alors les gens peuvent essayer.

Donc, cela mène à votre question

  • Comment sécurisez-vous votre algorithme et vos données?

Découragement

Obfuscation

L'option que vous suggérez, obscurcir le code, perturbe les aspects économiques ci-dessus - elle essaie d'augmenter considérablement le coût pour eux (5 ci-dessus) sans en augmenter beaucoup le coût (6). Les recherches menées par le Centre des fonctionnalités chiffrées ont mené à des recherches intéressantes à ce sujet. Le problème est que, comme avec le cryptage de DVD, il est voué à l'échec s'il y a suffisamment de différence entre 3, 4 et 5, alors quelqu'un finira par le faire.

Détection

Une autre option pourrait être une forme de stéganographie, qui vous permet d'identifier qui a déchiffré vos données et commencé à les distribuer. Par exemple, si vous avez 100 valeurs flottantes différentes dans vos données et qu'une erreur de 1 bit dans le LSB de chacune de ces valeurs ne poserait pas de problème avec votre application, encodez un (à chaque client) dans ces bits. Le problème est que si quelqu'un a accès à plusieurs copies des données de votre application, il serait évident que cela diffère, ce qui facilite l'identification du message caché.

Protection

SaaS - Logiciel en tant que service

Une option plus sûre pourrait être de fournir la partie critique de votre logiciel en tant que service, plutôt que de l'inclure dans votre application.

Conceptuellement, votre application collecterait toutes les données nécessaires à l'exécution de votre algorithme, la mettrait en package sous forme de requête à un serveur (contrôlé par vous) dans le cloud , votre service calculera ensuite vos résultats et le renvoyer au client, qui l'affichera.

Cela garde toutes vos données et algorithmes exclusifs et confidentiels dans un domaine que vous contrôlez complètement, et supprime toute possibilité qu'un client extrait l'un ou l'autre.

L'inconvénient évident est que les clients sont liés à votre prestation de services, sont à la merci de vos serveurs et de leur connexion Internet. Malheureusement, de nombreuses personnes s'opposent au SaaS pour exactement ces raisons. Sur le plan positif, ils sont toujours à jour avec les correctifs de bogues, et votre cluster de calcul sera probablement plus performant que le PC sur lequel ils exécutent l'interface utilisateur.

Ce serait un énorme pas en avant pour prendre cependant, et pourrait avoir un coût énorme 6 ci-dessus, mais c'est l'un des rares moyens de garder votre algorithme et vos données complètement sécurisés .

Dongles de protection logicielle

Bien que les dongles de protection logicielle traditionnels protègent contre le piratage de logiciels, ils ne protègent pas contre les algorithmes et les données de votre code en cours d'extraction.

Les nouveaux dongles de portage de code (tels que SenseLock † ) semble cependant pouvoir faire ce que vous voulez. Avec ces appareils, vous retirez le code de votre application et le portez vers le processeur de clé de sécurité sécurisée. Comme avec le SaaS, votre application regrouperait les données, les transmettrait au dongle (probablement un périphérique USB connecté à votre ordinateur) et relirait les résultats.

Contrairement au SaaS, la bande passante des données ne serait probablement pas un problème, mais les performances de votre application peuvent être limitées par les performances de votre SDP.

† C'était le premier exemple que j'ai pu trouver avec une recherche Google.

Plateforme de confiance

Une autre option, qui pourrait devenir viable à l'avenir, consiste à utiliser un module de plateforme de confiance et une technologie d'exécution de confiance pour sécuriser les zones du code. Chaque fois qu'un client installe votre logiciel, il vous fournira une empreinte digitale de son matériel et vous lui fournissez une clé de déverrouillage pour ce système spécifique.

Cette clé permettrait alors de déchiffrer le code et exécuté dans l'environnement de confiance, où le code et les données cryptés seraient inaccessibles en dehors de la plate-forme de confiance. Si quoi que ce soit dans l'environnement de confiance changeait, cela invaliderait la clé et cette fonctionnalité serait perdue.

Pour le client, cela présente l'avantage que ses données restent locales et qu'il n'a pas besoin d'acheter un nouveau dongle pour améliorer les performances, mais il a le potentiel de créer une exigence d'assistance continue et la probabilité que vos clients soient frustrés par les obstacles qu'ils ont dû franchir pour utiliser les logiciels qu'ils ont achetés et payés - vous perdre de la bonne volonté.

Conclusion

Vous seul pouvez répondre si les aspects économiques du découragement ou de la protection conviennent à votre situation. Mais plus vous optez pour une protection, plus elle sera chère, et donc plus vous devrez risquer de la perdre pour la justifier.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...