Crypter les données dans l'application mobile et envoyer au service Web
Je développe une application mobile pour Android et iOs. Quelle est la meilleure pratique en matière de cryptage des données dans l'application mobile qui sera envoyée à un service Web?
Fondamentalement, je vais générer une chaîne qui se compose de certains paramètres comme le GPS et l'heure. Cette chaîne doit être chiffrée puis transmise à un service Web.
J'ai envisagé de le faire avec un cryptage asymétrique. Chiffrez la chaîne avec la clé publique (qui doit être codée en dur?) Et déchiffrez avec la clé privée. Parce que chaque application peut être rétroconçue, ce n'est pas du tout sécurisé. Après avoir trouvé la clé publique codée en dur et la fonction de génération de chaîne, il est facile de forger ce que vous voulez.
Toute contribution est très appréciée.
EDIT: Une approche plus claire de ma question: une fonction de mon application va générer une chaîne et une autre fonction va crypter cette chaîne, qui sera envoyée à un serveur. Comment puis-je empêcher une chaîne auto-conçue d'être transmise à la fonction de chiffrement après l'ingénierie inverse de mon application? En d'autres termes, puis-je garantir avec une technique de cryptage que les données envoyées par mon application mobile à un serveur ne sont pas conçues par quelqu'un d'autre?
Tu ne peux pas. Il s'agit d'un principe fondamental de l'informatique à usage général.
Vous rencontrez la maxime de Shannon:
L'ennemi connaît le système. On devrait concevoir des systèmes en supposant que l'ennemi se familiarisera immédiatement avec eux.
Juste pour que mon point de vue soit tout à fait clair: vous donnez une voiture à quelqu'un et vous lui demandez de ne conduire qu'en un seul endroit. Rien ne les empêche de décider d'aller ailleurs - vous comptez sur eux pour qu'ils adhèrent à votre demande.
Si votre mécanisme de sécurité repose sur l'espoir que quelqu'un ne regarde pas votre exécutable et ne découvre pas votre méthode de chiffrement/clés intégrées, alors ce n'est pas un mécanisme de sécurité; c'est un mécanisme d'obscurité.
D'après ce que je peux dire, vous essayez de faire en sorte que les utilisateurs se trouvent dans une zone spécifiée via les coordonnées GPS et que vous souhaitez également vous assurer de ne pas usurper ces coordonnées. Cela ne peut pas être fait sur une plate-forme informatique à usage général telle qu'un smartphone. Regardons la pile technologique:
- Votre webapp se trouve quelque part dans "le cloud". Vous contrôlez tout cela.
- Votre application se trouve sur un téléphone. Le cas échéant, vous avez un contrôle minimal sur cela. Les vecteurs d'attaque possibles incluent l'ingénierie inverse, la modification d'application, les demandes directes d'application Web, l'édition de mémoire, etc.
- Le système d'exploitation du smartphone (par exemple Android ou iOS) fonctionne sur l'appareil. Vous n'avez aucun contrôle sur cela. Il est responsable de la communication avec l'appareil GPS et de la traduction des données en coordonnées utilisables. Les vecteurs d'attaque possibles incluent : fausses coordonnées GPS via le panneau de test (la plupart des téléphones ont cette fonctionnalité), pilote GPS modifié, API GPS accrochées, etc.
- Le module GPS est à l'intérieur de l'appareil. Vous n'avez aucun contrôle sur cela. Le module GPS est chargé de communiquer avec les satellites GPS et de relayer les données à la CPU via un bus standard. Les vecteurs d'attaque possibles incluent: l'homme au milieu sur le bus, le faux module GPS de remplacement, le faux signal satellite GPS provenant d'une radio définie par logiciel, etc.
Ainsi, vous ne pouvez pas imposer que les coordonnées GPS que vous recevez dans votre application Web sont correctes, car elles peuvent avoir été altérées au niveau de l'application, du niveau du système d'exploitation, du niveau matériel ou même du niveau du signal GPS. Ou, sauf tout cela, quelqu'un pourrait simplement ignorer le téléphone et envoyer manuellement des demandes à votre application Web contenant des données bidon!
La solution consiste à accepter le risque ou à modifier votre modèle de sécurité.
Vous devez toujours utiliser SSL.
SSL a une clé publique intégrée et prévoit une "authentification", ce qui signifie qu'il garantit que le serveur avec lequel vous communiquez est bien le service Web que vous souhaitez, et non un imposteur.
Puisque vous n'indiquez pas le contraire, ou tout autre besoin que vous avez, je pense que SSL résoudra toutes vos préoccupations concernant l'envoi de données à un serveur et leur sécurisation en transit.
Mise à jour
Sur la base de vos exigences mises à jour dans les commentaires, je comprends que vous souhaitez empêcher l'usurpation des données GPS envoyées à votre service Web.
Si vous n'avez aucun contrôle sur l'appareil (administratif ou autre), ce que @Polynomial dit est correct. Si vous créez un système fermé, intégré ou si vous êtes dans une société, vous pouvez avoir plus d'options.
Supposons que vous ayez le contrôle total de chaque téléphone sur lequel votre application s'exécutera. Cela signifie verrouiller le téléphone, maintenir le contrôle exclusif du mot de passe administrateur et ne jamais le donner aux utilisateurs finaux.
Ensuite, vous pouvez attribuer à chaque appareil une clé unique pour crypter les données à envoyer à un service Web.
Si un téléphone donné est compromis, vous serez en mesure de déterminer quel appareil il était basé sur la clé utilisée.
La meilleure pratique dépend de l'utilisation exacte.
Ce que je comprends de votre question, c'est que vous avez une application qui vous envoie des données GPS et de l'heure, comme une application "footprint". Vous voulez vous assurer que vous ne recevez pas de fausses données, et vous voulez donc vous assurer que les données proviennent de votre vrai client et non d'un faux.
Eh bien, malheureusement, comme d'autres réponses l'ont indiqué, c'est impossible. Étant donné le fichier APK de votre application, quelqu'un peut très facilement le décompiler en Java, peut-être pas aussi élégant que votre propre source, mais certainement réalisable. Ils peuvent ensuite utiliser votre code pour construire leur propre application, qui communique avec la vôtre exactement comme vous l'attendez, et l'utilise pour vous fournir de fausses données.
Par conséquent, le schéma que vous utilisez pour le transport de données doit jamais faire confiance au client. Il devrait plutôt faire confiance à tilisateur.
Considérez cette solution; votre serveur d'applications est signé avec un certificat de clé publique de confiance (il peut, dans ce cas, être approuvé pour la seule raison que votre application connaît le certificat exact qu'il doit être donné; cela s'appelle "certificat épinglage "et cela fonctionne que vous ayez obtenu le certificat signé par une autorité de certification mondiale ou non). Sur demande, il présente ce certificat à celui qui le demande; c'est une information publique, vous pouvez plâtrer cette chose sur chaque forum de hackers sur Internet et ce ne serait pas moins sûr. Votre client utilise ce certificat pour négocier un tunnel de communication sécurisé; c'est assez standard.
Maintenant, vous avez confidentialité. Vous avez besoin de authenticité; peu importe que personne d'autre ne puisse écouter la conversation entre vous deux si vous ne savez pas avec certitude qui est à l'autre bout. Ainsi, une fois le canal ouvert, la prochaine chose à laquelle vous vous attendez est une demande d'authentification contenant les informations d'identification de l'utilisateur. Vous devez rejeter toute demande d'envoi de données GPS si la session n'a pas été authentifiée. Les informations d'identification que l'utilisateur fournit dans une telle demande peuvent être leur nom d'utilisateur et leur mot de passe, l'adresse IMEI ou MAC de leur téléphone, le code à 10 chiffres d'un porte-clés de chiffrement, tout ce que vous pensez nécessaire pour garantir correctement que niquement = un utilisateur particulier pourrait être en mesure de fournir ces informations d'identification.
Une fois que vous disposez de ces informations d'identification et que vous avez vérifié qu'elles correspondent aux attentes, quelle que soit la manière dont vous le souhaitez, vous leur renvoyez un "jeton d'authentification". C'est aussi simple qu'un nombre aléatoire distinct de celui utilisé pour toute autre session ouverte. Un GUID V4 est également un très bon choix. Cet identifiant sera requis dans le cadre de toute demande d'envoi ou de réception de données sur ce canal au cours de cette session, il niquement sera accepté sur ce canal particulier, et niquement aussi longtemps car cette session unique est ouverte.
Une fois que tout cela est configuré, tout appel de service qui a été effectué sur le canal sécurisé de cette session qui comprend le jeton d'authentification correct peut généralement être approuvé. Vous devriez probablement inclure une dernière chose, qui est une mesure de protection contre les attaques par rejeu. Un attaquant n'a pas besoin de savoir exactement ce qui est envoyé dans les deux sens pour vous gâcher en répétant simplement ce qui a déjà été dit. Ainsi, pour vous assurer que votre système ne traite un message unique qu'une seule fois, quel que soit le nombre de fois qu'il est envoyé, chaque message doit inclure un nonce, une valeur unique utilisée une seule fois. Une simple valeur de compteur de séquence, faisant partie de la structure de la demande et chiffrée par le canal sécurisé, devrait suffire pour cela; alors, tout ce que vous avez à faire est d'ignorer tout message dont le numéro de séquence n'est pas le prochain que vous vous attendez à recevoir du client (il peut y avoir une tolérance aux pannes inhérente à cela, mais jamais accepter la même chose type de demande de service du même client avec le même numéro de séquence deux fois).