Clés sécurisées dans le scénario de l'application iOS, est-ce sûr?
J'essaie de cacher 2 secrets que j'utilise dans l'une de mes applications.
Si je comprends bien, le trousseau est un bon endroit, mais je ne peux pas les ajouter avant de soumettre l'application.
J'ai pensé à ce scénario -
- Pré-semez les secrets dans la base de données CoreData de mon application en les diffusant dans d'autres entités pour les obscurcir. (J'ai déjà une base de données de semences dans cette application).
- Lorsque l'application se lance pour la première fois, générez et déplacez les clés vers le trousseau.
- Supprimez les enregistrements de CoreData.
Est-ce sûr ou le pirate peut-il voir cela se produire et obtenir ces clés?
* TROISIÈME MODIFICATION ** Désolé de ne pas expliquer ce scénario depuis le début - L'application a de nombreux niveaux, chaque niveau contient des fichiers (audio, vidéo, images). L'utilisateur peut acheter un niveau (IAP) et une fois l'achat terminé, je dois télécharger les fichiers sur son appareil.
Pour iOS6, les fichiers sont stockés avec Apple nouvelle fonctionnalité "Contenu hébergé". Pour iOS5, les fichiers sont stockés dans Amazon S3.
Donc, dans tout ce processus, j'ai 2 clés: 1. Clé IAP, pour vérifier l'achat à Apple IAP. 2. Clés S3, pour obtenir les fichiers de S3 pour les utilisateurs iOS5:
NSString *secretAccessKey = @"xxxxxxxxx";
NSString *accessKey = @"xxxxxxxxx";
Dois-je absolument protéger ces clés? J'ai peur que les gens puissent obtenir les fichiers de S3 sans acheter les niveaux. Ou que les pirates pourront créer une version piratée avec tous les niveaux pré-téléchargés à l'intérieur.
Permettez-moi d'essayer de décomposer votre question en plusieurs sous-questions/hypothèses:
Hypothèses:
a) Le trousseau est un endroit sûr
En fait, ce n'est pas si sûr. Si votre application est installée sur un appareil jailbreaké, un pirate pourra récupérer vos clés depuis le trousseau
Des questions:
a) Existe-t-il un moyen de mettre une clé dans une application (binaire qui est fourni depuis l'AppStore) et d'être complètement sécurisé?
La réponse courte est NON. Dès qu'il y a quelque chose dans votre binaire, il peut être rétroconçu.
b) L'obscurcissement sera-t-il utile?
Oui. Cela augmentera le temps pour un pirate de le comprendre. Si les clés que vous avez dans l'application "coûteront" moins d'un temps consacré à la rétro-ingénierie - en général, vous êtes bon.
Cependant, dans la plupart des cas, la sécurité par l'obscurité est une mauvaise pratique, elle vous donne le sentiment que vous êtes en sécurité, mais vous ne l'êtes pas.
Donc, cela pourrait être l'une des mesures de sécurité, mais vous devez également mettre en place d'autres mesures de sécurité.
c) Que dois-je faire dans ce cas? *
Il est difficile de vous donner une bonne solution sans savoir ce que vous essayez de faire.
Par exemple, pourquoi tout le monde devrait avoir accès au même Amazon S3? Ont-ils besoin de lecture seule ou d'écriture (comme l'a souligné Kendall Helmstetter Gein).
Je crois que l'un des scénarios les plus sûrs serait quelque chose comme ça:
- Votre application doit être protégée par un mot de passe
- La première fois que vous entrez dans votre application, il demande à un utilisateur de s'authentifier (entrez son nom d'utilisateur, son mot de passe) sur le serveur
- Cela s'authentifie auprès de votre serveur ou d'un autre fournisseur d'authentification (par exemple Google)
- Le serveur envoie un jeton d'authentification à un appareil (il s'agit souvent d'un type de cookie).
- Vous cryptez ce jeton en fonction du hachage de votre mot de passe d'application et l'enregistrez dans le trousseau sous cette forme
- Et maintenant, vous pouvez faire deux choses:
- remettre des clés spécifiques du serveur au client (pour que chaque client ait ses propres clés) et les chiffrer avec le hachage de votre code d'accès d'application
- gérer toutes les opérations avec S3 sur le serveur (et exiger que le client envoie)
De cette façon, vous vous protégez de plusieurs attaques possibles.
c) Whoooa .... Je ne prévois pas de mettre en œuvre tous ces trucs que vous venez d'écrire, car cela me prendra des mois. Y a-t-il quelque chose de plus simple?
Je pense que ce serait utile si vous avez un jeu de clés par client.
Si même cela est trop, téléchargez les clés cryptées depuis le serveur et enregistrez-les sous forme cryptée sur l'appareil et faites coder en dur la clé de décryptage dans votre application. Je dirais que c'est peu invasif et au moins votre binaire n'a pas de clés.
P.S. Kendall et Rob ont raison.
Mise à jour 1 (basée sur de nouvelles informations)
Tout d'abord, avez-vous vu dans le guide de programmation d'achat d'applications .
Il y a un très bon dessin sous Modèle de produit serveur. Ce modèle protège contre quelqu'un qui n'a pas acheté de nouveaux niveaux. Il n'y aura pas de clés Amazon intégrées dans votre application et votre côté serveur remettra les niveaux lorsqu'il recevra la réception de l'achat.
Il n'y a pas de solution parfaite pour se protéger contre quelqu'un qui a acheté le contenu (et a décidé de le retirer de votre application), car à la fin des jours, votre application aura le contenu téléchargé sur un appareil et en aura besoin en clair (forme non cryptée) ) à un moment donné.
Si vous êtes vraiment préoccupé par cette affaire, je vous recommande de crypter tous vos actifs et de les remettre sous forme cryptée à partir du serveur avec la clé de cryptage. La clé de chiffrement doit être générée par client et l'actif doit être chiffré à l'aide de celle-ci.
Cela n'empêchera aucun pirate informatique avancé, mais au moins cela protégera de quelqu'un utilisant iExplorer et juste de copier des fichiers (car ils seront cryptés).
Update 2
Une dernière chose concernant la mise à jour 1. Vous devez stocker les fichiers non cryptés et stocker la clé de cryptage quelque part (par exemple dans le trousseau).
Dans le cas où votre jeu nécessite une connexion Internet, la meilleure idée est de ne pas stocker du tout de clé de cryptage sur l'appareil. Vous pouvez l'obtenir à partir du serveur à chaque démarrage de votre application.
NE PAS stocker une clé S3 utilisée pour écrire dans votre application! Dans un court ordre, quelqu'un qui renifle du trafic verra l'appel d'écriture vers S3, dans un ordre plus court, il trouvera cette clé et fera ce qu'il voudra.
La SEULE manière dont une application peut écrire du contenu sur S3 avec n'importe quel degré de sécurité est de passer par un serveur que vous contrôlez.
S'il s'agit d'une clé utilisée en lecture seule, ce qui signifie que votre S3 ne peut pas être lu en public mais que la clé peut être utilisée pour un accès en lecture seule sans possibilité d'écrire, vous pouvez l'intégrer dans l'application, mais toute personne qui le souhaite peut la retirer. en dehors.
Pour obscurcir légèrement les données sensibles préchargées, vous pouvez les crypter dans un fichier et l'application peut les lire en mémoire et décrypter avant de les stocker dans le trousseau. Encore une fois, quelqu'un sera en mesure d'accéder à ces clés, il vaut donc mieux peu importe s'il le peut.
Éditer:
Sur la base de nouvelles informations, vous feriez probablement mieux d'incorporer les secrets dans le code. En utilisant un outil comme iExplorer, un utilisateur causal peut facilement accéder à une base de données de données de base ou à tout autre élément de votre ensemble d'applications, mais les fichiers objets sont quelque peu chiffrés. S'ils ont un appareil jailbreaké, ils peuvent facilement obtenir les versions non cryptées, mais il peut toujours être difficile de trouver des chaînes significatives, peut-être de les stocker en deux parties et de les réassembler dans le code.
Encore une fois, cela n'empêchera pas un pirate informatique déterminé, mais cela suffit pour empêcher la plupart des gens d'entrer.
Vous pouvez également ajouter du code qui tenterait de demander à votre serveur s'il existe des secrets de remplacement qu'il peut télécharger. De cette façon, si les secrets sont divulgués, vous pouvez réagir rapidement en modifiant les secrets utilisés pour votre application, tout en excluant toute personne utilisant un secret copié. Pour commencer, il n'y aurait aucun remplacement à télécharger. Vous ne voulez pas avoir à attendre une mise à jour d'application pour pouvoir utiliser de nouvelles clés.
Il n'y a aucun bon moyen de cacher un secret dans un morceau de code que vous envoyez à votre attaquant. Comme avec la plupart des choses de ce type, vous devez vous concentrer davantage sur la façon d'atténuer le problème lorsque la clé fuit plutôt que de passer un temps illimité à essayer de la protéger. Par exemple, la génération de clés différentes pour chaque utilisateur vous permet de désactiver une clé si elle est utilisée de manière abusive. Ou travailler via un serveur intermédiaire vous permet de contrôler le protocole (c'est-à-dire que le serveur a la clé et est seulement disposé à faire certaines choses avec).
Ce n'est pas une perte de temps de faire un peu de brouillage. C'est très bien. Mais n'y consacrez pas beaucoup de temps. Si c'est dans le programme et qu'il est très précieux, il sera piraté. Concentrez-vous sur la façon de détecter quand cela se produit et comment récupérer quand cela se produit. Et autant que possible, déplacez ce type de données sensibles vers un autre serveur que vous contrôlez.