Protection des clés secrètes API dans une application client lourd

Question

Dans une application, j'ai des clés secrètes utilisées pour calculer un hachage pour un appel API.Dans une application .NET, il est assez facile d'utiliser un programme tel que Reflector pour extraire des informations de l'assembly afin d'inclure ces clés.

Le fait de masquer l'assemblage est-il un bon moyen de sécuriser ces clés ?

Answer 1

Probablement pas.

Examinez la cryptographie et les mécanismes de masquage d'informations intégrés à Windows (DPAPI et stockage des clés dans une clé de registre restreinte par ACL, par exemple).C'est tout ce que vous obtiendrez en matière de sécurité, vous devez conserver le même système que votre application.

Si vous cherchez un moyen d’empêcher quelqu’un physiquement assis devant la machine d’obtenir vos informations, oubliez-le.Si quelqu'un est déterminé et dispose d'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 de déterminé s’y mettra s’il le souhaite.

Answer 2

Je ne le pense pas, car obscurcir (si je le comprends du moins) va simplement jouer avec les noms de méthodes pour rendre difficile (mais pas impossible) la compréhension du code.Cela ne changera pas les données de la clé réelle (que je suppose que vous avez stockée dans une constante quelque part).

Si vous voulez simplement le rendre un peu plus difficile à voir, vous pouvez exécuter un simple chiffre sur le texte en clair (comme ROT-13 ou quelque chose du genre) afin qu'il ne soit au moins pas stocké en clair dans le code lui-même.Mais cela n’empêchera certainement pas un pirate informatique déterminé d’accéder à votre clé.Une méthode de cryptage plus forte n'aidera pas car vous devrez toujours stocker la clé pour CELA dans le code, et rien ne la protège.

La seule chose vraiment sécurisée à laquelle je puisse penser est de conserver la clé en dehors de l'application, puis de 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 empêcher les utilisateurs non autorisés d'accéder à la base de données).

J'ai joué avec l'idée de faire cela pour mes applications mais je ne l'ai jamais implémenté.

Answer 3

DannySmurf a raison de dire que vous ne pouvez pas cacher les clés à la personne qui exécute une application ;si l’application peut accéder aux clés, la personne le peut aussi.

Cependant, qu’essayez-vous d’accomplir exactement ?

Selon ce dont il s'agit, il existe souvent des moyens d'atteindre votre objectif qui ne reposent pas simplement sur la conservation d'un "secret" secret sur la machine de votre utilisateur.

Answer 4

En retard pour le jeu ici...

L'approche consistant à stocker les clés dans la configuration assembly/assembly est fondamentalement non sécurisée.Il n’existe aucun moyen irréprochable de le stocker car un utilisateur déterminé y aura accès.Je m'en fiche si vous utilisez le produit d'obscurcissement le meilleur/le plus cher de la planète.Peu m'importe si vous utilisez PDAPI pour sécuriser les données (même si c'est mieux).Cela m'est égal si vous utilisez un magasin de clés local protégé par le système d'exploitation (c'est encore mieux).Aucun n’est idéal car tous souffrent du même problème fondamental :l'utilisateur a accès aux clés, et elles sont là, inchangées pendant des jours, des semaines, voire des mois et des années.

Une approche beaucoup plus sécurisée consisterait à sécuriser vos appels API avec une PKI éprouvée.Cependant, cela entraîne une surcharge de performances évidente si vos appels d'API sont bavards, mais pour la grande majorité des applications, ce n'est pas un problème.

Si les performances sont un problème, vous pouvez utiliser Diffie-Hellman sur une PKI asymétrique pour établir une clé symétrique secrète partagée à utiliser avec un chiffrement tel qu'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 / intégrée.N'importe où.

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 secrètes partagées 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 valables que pour une très courte période, et uniquement 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 servent qu’à interférer avec la communication locale.Ils ne peuvent pas utiliser ces connaissances pour affecter d'autres utilisateurs, contrairement à une clé intégrée partagée par tous les utilisateurs via code/config.

De plus, l’intégralité des clés elles-mêmes ne sont jamais transmises 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 un tiers Charlie, lui permettant de calculer indépendamment la clé secrète partagée.C'est pourquoi vous utilisez cette PKI asymétrique (beaucoup 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 bien souvent couplée à une authentification et donc à une création de session.Vous vous "connectez" et créez votre "session" via PKI, et une fois cette opération terminée, le client et le serveur disposent indépendamment d'une clé symétrique qui peut être utilisée pour un cryptage plus rapide d'un ordre de grandeur pour toutes les communications ultérieures au cours de cette session.Pour les serveurs à grande échelle, il est important d'économiser les cycles de calcul lors du décryptage plutôt que d'utiliser, par exemple, TLS pour tout.

Mais attendez:nous ne sommes pas encore en sécurité.Nous avons seulement empêché la lecture des messages.

Notez qu'il est toujours nécessaire d'utiliser un mécanisme de résumé de message pour empêcher toute manipulation de l'homme du milieu.Si personne ne peut lire les données transmises, sans MD, rien n'empêche de les modifier.Vous hachez donc le message avant le cryptage, puis envoyez le hachage avec le message.Le serveur hache ensuite à nouveau la charge utile lors du déchiffrement et vérifie qu'elle correspond au hachage qui faisait partie du message.Si le message a été modifié en cours de transit, ce ne sera pas le cas et l'intégralité du message est rejetée/ignorée.

Le dernier mécanisme nécessaire pour se prémunir contre les attaques par rejeu est celui des attaques par rejeu.À ce stade, vous avez empêché les gens de lire vos données, ainsi que de modifier vos données, mais vous ne les avez pas empêchés de simplement les renvoyer.S'il s'agit d'un problème pour votre application, son protocole doit fournir des données et le client et le serveur doivent disposer de 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 chiffrée.Notez que si vous utilisez un transport tel qu'UDP, vous disposez probablement déjà d'un mécanisme pour gérer les paquets dupliqués, et pouvez donc déjà gérer les attaques par relecture.

Ce qui devrait être évident, c’est que bien faire les choses n’est pas facile.Ainsi, utilisez PKI à moins que vous ne le 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 calcul possible sur chaque joueur pour obtenir une plus grande évolutivité, tout en offrant une sécurité contre le piratage et les regards indiscrets.

Donc, en conclusion, si c'est vraiment quelque chose qui vous préoccupe, au lieu d'essayer de trouver un stockage sécurisé des clés API, ne le faites pas.Au lieu de cela, modifiez la façon dont votre application utilise cette API (en supposant que vous contrôlez les deux côtés, naturellement).Utilisez une PKI ou utilisez un hybride symétrique partagé par PKI si la PKI est trop lente (ce qui est RAREMENT un problème de nos jours).Vous n’aurez alors rien stocké qui pose un problème de sécurité.