Au sein d'une application, j'ai utilisé les clés secrètes pour calculer un hachage pour un appel d'API. Dans une application .NET, il est assez facile d'utiliser un programme tel que Reflector pour extraire des informations de l'assemblage afin d'inclure ces clés.Protection des clés secrètes de l'API dans une application client lourd
Est-ce que masquer l'assemblage est un bon moyen de sécuriser ces clés?
Probablement pas.
Examinez la cryptographie et les mécanismes cachés de dissimulation d'informations de Windows (DPAPI et stockez les clés dans une clé de registre à restriction ACL, par exemple). C'est aussi bon que vous allez obtenir pour la sécurité que vous devez garder sur le même système que votre application.
Si vous cherchez un moyen d'empêcher quelqu'un assis physiquement sur la machine d'obtenir vos informations, oubliez-le. Si quelqu'un est déterminé, et a un accès illimité à un ordinateur qui n'est pas sous votre contrôle, il n'y a aucun moyen d'être sûr à 100% que les données sont protégées en toutes circonstances. Quelqu'un qui est déterminé y arrivera s'il le veut.
Je ne le pense pas, car obscurcir (comme je le comprends au moins) va tout simplement jouer avec les noms de méthodes pour rendre difficile (mais pas impossible) de comprendre le code. Cela ne changera pas les données de la clé actuelle (que je suppose que vous avez stocké dans une constante quelque part). Si vous voulez juste le rendre un peu plus difficile à voir, vous pouvez exécuter un chiffrement simple sur le texte en clair (comme ROT-13 ou quelque chose) afin qu'il ne soit pas stocké en clair dans le code lui-même. Mais cela ne va certainement pas empêcher un pirate déterminé d'accéder à votre clé. Une méthode de cryptage plus puissante n'aidera pas parce que vous auriez encore besoin de stocker la clé pour CELA dans le code, et rien ne le protège.
La seule chose vraiment sûre que je peux penser est de garder la clé en dehors de l'application en quelque sorte, puis restreindre l'accès à la clé. Par exemple, vous pouvez conserver la clé dans un fichier séparé, puis protéger le fichier avec une restriction basée sur l'utilisateur au niveau du système d'exploitation; cela fonctionnerait probablement. Vous pouvez faire la même chose avec une connexion à une base de données (encore une fois, en vous appuyant sur la restriction d'accès basée sur l'utilisateur pour garder les utilisateurs non autorisés hors de la base de données).
J'ai eu l'idée de le faire pour mes applications mais je ne l'ai jamais implémenté.
DannySmurf est correct que vous ne pouvez pas cacher les clés de la personne qui exécute une application; Si l'application peut accéder aux clés, la personne peut le faire.
Cependant, qu'est-ce que vous essayez d'accomplir exactement? En fonction de ce que c'est, il existe souvent des moyens d'atteindre votre objectif qui ne se contentent pas de garder un secret "secret" sur la machine de votre utilisateur.
tard pour le jeu ici ...
L'approche de stockage des clés dans la configuration de montage/assemblage est fondamentalement peu sûr. Il n'y a pas de moyen possible de le stocker comme un utilisateur déterminé aura accès. Je m'en fous si vous utilisez le produit d'obfuscation le meilleur/le plus cher sur la planète. Je m'en fous si vous utilisez PDAPI pour sécuriser les données (bien que ce soit mieux). Je m'en fous si vous utilisez un magasin de clés protégé par OS (c'est encore mieux). Aucun n'est idéal car tous souffrent du même problème de base: l'utilisateur a accès aux clés, et elles sont là, immuables pendant des jours, des semaines, voire des mois et des années.
Une approche beaucoup plus sécurisée serait de sécuriser vos appels API avec une PKI éprouvée. Toutefois, cela entraîne des pertes de performances évidentes si vos appels d'API sont bavards, mais pour la grande majorité des applications, cela ne pose aucun problème. Si les performances sont un problème, vous pouvez utiliser Diffie-Hellman sur une ICP asymétrique pour établir une clé secrète secrète partagée à utiliser avec un chiffrement tel que AES. "partagé" dans ce cas signifie partagé entre le client et le serveur, pas tous les clients/utilisateurs. Il n'y a pas de clé codée en dur. Nulle part.
Les clés sont transitoires, régénérées chaque fois que l'utilisateur exécute le programme, ou si vous êtes vraiment paranoïaque, elles peuvent expirer et nécessiter une récréation.
Les clés symétriques à secret partagé calculées elles-mêmes sont stockées en mémoire uniquement, dans SecureString. Ils sont difficiles à extraire, et même si vous le faites, ils ne sont bons que pour très peu de temps, et seulement pour la communication entre ce client particulier (c'est-à-dire cette session). En d'autres termes, même si quelqu'un pirate ses clés locales, elles ne sont bonnes que pour interférer avec la communication locale. Ils ne peuvent pas utiliser cette connaissance pour affecter d'autres utilisateurs, contrairement à une clé intégrée partagée par tous les utilisateurs via code/config.
En outre, les clés entières elles-mêmes ne sont jamais, jamais passées sur le réseau. Le client Alice et le serveur Bob les calculent indépendamment. Les informations qu'ils transmettent pour ce faire pourraient en théorie être interceptées par le tiers Charlie, lui permettant de calculer indépendamment la clé secrète partagée. C'est pourquoi vous utilisez cette ICP asymétrique (nettement plus coûteuse) pour protéger la génération de clé entre Alice et Bob.
Dans ces systèmes, la génération de clé est assez souvent couplée à l'authentification et donc à la création de session. Vous vous "connectez" et créez votre "session" sur PKI, et après cela est terminé, le client et le serveur ont indépendamment une clé symétrique qui peut être utilisée pour un cryptage plus rapide pour toute communication ultérieure dans cette session. Pour les serveurs à grande échelle, il est important de sauvegarder les cycles de calcul lors du décryptage en utilisant say TLS pour tout.
Mais attendez: nous ne sommes pas encore en sécurité. Nous avons seulement empêché de lire les messages.
Notez qu'il est toujours nécessaire d'utiliser un mécanisme de résumé de message pour empêcher la manipulation du man-in-the-middle. Alors que personne ne peut lire les données transmises, sans MD, rien ne les empêche de les modifier. Donc vous hachez le message avant le cryptage, puis envoyez le hachage avec le message. Le serveur redessine alors la charge utile lors du déchiffrement et vérifie qu'il correspond au hachage qui faisait partie du message. Si le message a été modifié pendant le transport, ils ne le seront pas et le message entier est ignoré/ignoré.
Le dernier mécanisme nécessaire pour se prémunir contre les attaques par relecture. À ce stade, vous avez empêché les utilisateurs de lire vos données et de modifier vos données, mais vous ne les avez pas empêchés de les envoyer à nouveau. Si c'est un problème pour votre application, son protocole doit fournir des données et le client et le serveur doivent avoir suffisamment d'informations avec état pour détecter une relecture. Cela pourrait être quelque chose d'aussi simple qu'un compteur faisant partie de la charge utile cryptée. Notez que si vous utilisez un transport tel que UDP, vous avez probablement déjà un mécanisme pour traiter les paquets dupliqués, et pouvez donc déjà gérer les attaques de rejeu.
Ce qui devrait être évident, c'est que ce n'est pas facile. Ainsi, utilisez l'ICP à moins que vous ne puissiez ABSOLUMENT pas. Notez que cette approche est largement utilisée dans l'industrie du jeu où il est hautement souhaitable de dépenser le moins de ressources possible sur chaque lecteur pour atteindre une plus grande évolutivité, tout en assurant la sécurité contre les attaques de piratage.Donc, en conclusion, si c'est vraiment quelque chose qui est une préoccupation, au lieu d'essayer de trouver un stockage sécurisé des clés de l'API, ne le faites pas. Au lieu de cela, changez la façon dont votre application utilise cette API (en supposant que vous avez le contrôle des deux côtés, naturellement). Utilisez une PKI ou utilisez un hybride symétrique à partage PKI si l'ICP est trop lente (ce qui pose RAREMENT un problème de nos jours). Vous n'aurez alors rien stocké qui soit un problème de sécurité.
Ça fait peur qu'il n'y ait aucun moyen, mais je suis d'accord parce que c'est un fait. – Shimmy