Vérification de l'intégrité de l'application Android côté serveur
J'ai Android (services bancaires mobiles) qui se connectent à mon serveur et effectuent des transactions en ligne (via Internet/USSD/SMS), je veux m'assurer que ces clients ne sont pas falsifiés et sont l'original ceux distribués par moi.
Gardez à l'esprit que tous mes clients ne téléchargent pas l'application via google play, certains d'entre eux utilisent des marchés tiers ou téléchargent l'apk ailleurs.
Existe-t-il un moyen de valider l'intégrité de l'application (en utilisant une somme de contrôle ou une signature) côté serveur pour m'assurer qu'elle n'est pas falsifiée. (par exemple, un cheval de Troie n'est pas implanté dans l'application, puis redistribué)
Pour les solutions suggérées:
- Peuvent-ils être mis en œuvre sur les 3 canaux de communication (SMS/USSD/Internet) ou les solutions sont-elles propriétaires d'un/de certains canaux?
(Je cherche exactement la technique à laquelle il est fait référence dans cette page: https://samsclass.info/Android/chase.htm ):
Les serveurs de Chase ne vérifient pas l'intégrité de leur application Android lorsqu'elle se connecte à leurs serveurs. Il est donc facile de modifier l'application en ajoutant du code de Troie qui fait des choses malveillantes. Un attaquant qui peut tromper les gens qui utilisent l'application troyenne peuvent les exploiter.
Cette vulnérabilité n'affecte pas les personnes qui utilisent l'application authentique du Google Play Store. Cela ne nuirait qu'aux personnes qui sont amenées à installer une application modifiée à partir d'un site Web, d'un courrier électronique, etc.
Utilisez Android SafetyNet . C'est ainsi que Android Pay se valide.
Le flux de base est:
- Votre serveur génère un nonce qu'il envoie à l'application cliente.
- L'application envoie une demande de vérification avec le nonce via les services Google Play.
- SafetyNet vérifie que le périphérique local n'est pas modifié et a passé le CTS .
- Une réponse signée par Google ("attestation") est renvoyée à votre application avec un résultat de réussite/d'échec et des informations sur l'APK de votre application (certificat de hachage et de signature).
- Votre application envoie l'attestation à votre serveur.
- Votre serveur valide la signature nonce et APK, puis soumet l'attestation à un serveur Google pour vérification. Google vérifie la signature d'attestation et vous indique si elle est authentique.
Si cela réussit, vous pouvez être assez sûr que l'utilisateur exécute une version authentique de votre application sur un système non modifié. L'application doit obtenir une attestation au démarrage et l'envoyer à votre serveur à chaque demande de transaction.
Notez cependant que cela signifie:
- Les utilisateurs qui ont rooté leur téléphone ne réussiront pas ces vérifications
- Les utilisateurs qui ont installé une ROM/un firmware/OS personnalisé ou tiers (par exemple Cyanogen) ne passeront pas ces vérifications
- Les utilisateurs qui n'ont pas accès aux services Google Play (par exemple, les appareils Amazon, les personnes en Chine) ne passeront pas ces contrôles
... et ne pourra donc pas utiliser votre application. Votre entreprise doit prendre une décision commerciale pour savoir si ces restrictions (et les utilisateurs contrariés qui les accompagnent) sont acceptables.
Enfin, sachez que ce n'est pas une solution entièrement étanche . Avec un accès root et peut-être Xposed, il est possible de modifier la bibliothèque SafetyNet pour mentir aux serveurs de Google, en leur disant les "bonnes" réponses pour obtenir un résultat de passe de vérification que Google signe. En réalité, SafetyNet déplace simplement les poteaux de but et le rend plus difficile pour les acteurs malveillants. Ces contrôles devant finalement s'exécuter sur un appareil hors de votre contrôle, il est en effet impossible de concevoir un système entièrement sécurisé.
Lisez ici une excellente analyse du fonctionnement des composants internes de SafetyNet.
La seule chose que le serveur peut déterminer de manière fiable sur un appareil est son comportement envers le serveur (les données reçues et dans quels modèles de temps). En supposant qu'un attaquant a la connaissance et le contrôle de tous les éléments qui influencent le comportement, l'attaquant peut créer un clone malveillant et le serveur ne le saura jamais.
Donc, techniquement, c'est impossible. À moins que vous n'utilisiez la prise en charge du matériel des appareils, le fichier APK entier est suffisant pour créer un clone malveillant (la décompilation est assez facile, proguard n'aidera pas beaucoup contre une rétro-ingénierie expérimentée).
Comme cela a été mentionné dans les commentaires de @ CodesInChaos et @ OrenMilman :
Vous pouvez inclure dans ce comportement des éléments très difficiles à saisir pour un attaquant, par ex. un TPM/TEE et implémenter une attestation à distance. En supposant que le TPM ne présente aucune vulnérabilité (ce qui est peu probable, mais supposons simplement), ce serait en effet une solution. De plus, la sécurité est inutile sans modèle de menace. Donc, si votre modèle de menace exclut les attaquants avec un dévouement à temps plein, beaucoup d'argent et éventuellement un accès à 0 jours, vous pouvez considérer un tel mécanisme comme sûr.
Je ne sais pas quels appareils Android ont un module de plateforme sécurisée et prennent en charge ces mesures; je laisserai cette recherche et modifierai cette réponse à quelqu'un d'autre.
J'arrive un peu tard pour la fête, mais je pense que je peux ajouter quelques idées utiles.
Existe-t-il un moyen de valider l'intégrité de l'application (en utilisant une somme de contrôle ou une signature) côté serveur pour m'assurer qu'elle n'est pas falsifiée. (par exemple, un cheval de Troie n'est pas implanté dans l'application, puis redistribué)
Pour une sécurité ultime entre votre application et le serveur API, vous devez utiliser un service d'attestation d'intégrité des applications mobiles avec la solution SafetyNet, le service OAUTH2. Il est également important d'utiliser l'épinglage de certificat pour sécuriser le canal de communication entre le serveur API et l'application mobile, comme indiqué dans cette série d'articles sur les techniques de l'API mobile.
Le rôle d'un service d'attestation d'intégrité d'application mobile est de garantir au moment de l'exécution que votre application n'a pas été falsifiée ou ne s'exécute pas sur un appareil enraciné en utilisant un SDK intégré à votre application et un service exécuté dans le cloud.
En cas d'attestation réussie de l'intégrité de l'application, un jeton JWT est émis et signé avec un secret que seuls le serveur API de votre application et le service d'attestation d'intégrité de l'application mobile dans le cloud sont conscients.
En cas d'échec de l'App Integrity Attestation, le JWT est signé avec un secret que le serveur API ne connaît pas.
Maintenant, l'application doit envoyer avec chaque appel d'API le jeton JWT dans les en-têtes de la demande. Cela permettra au serveur API de ne servir les demandes que s'il peut vérifier la signature dans le jeton JWT et de les refuser en cas d'échec de la vérification.
Une fois que le secret utilisé par le service d'attestation d'intégrité de l'application mobile n'est pas connu de l'application, il n'est pas possible de le rétroconcevoir au moment de l'exécution même lorsque l'application est falsifiée, exécutée sur un appareil enraciné ou communiquant via une connexion qui est la cible d'un homme dans l'attaque du milieu. C'est là que ce type de service brille par rapport à la solution SafetyNet.
Vous pouvez trouver un tel service dans Approov qui a des SDK pour plusieurs plates-formes, y compris Android. L'intégration nécessitera également une petite vérification dans le code du serveur API pour vérifier le jeton JWT afin de se protéger contre une utilisation frauduleuse.
Gardez à l'esprit que tous mes clients ne téléchargent pas l'application via google play, certains d'entre eux utilisent des marchés tiers ou téléchargent l'apk ailleurs.
Avec l'utilisation d'un service d'attestation d'intégrité de l'API mobile comme Approov , peu importe où l'application a été installée.
J'ai Android (services bancaires mobiles) qui se connectent à mon serveur et effectuent des transactions en ligne (via Internet/USSD/SMS), je veux m'assurer que ces clients ne sont pas falsifiés et sont l'original ceux distribués par moi.
et
Pour les solutions suggérées:
Peuvent-ils être mis en œuvre sur les 3 canaux de communication (SMS/USSD/Internet) ou les solutions sont-elles propriétaires d'un/de certains canaux?
Donc, en supposant que votre application parle directement avec les services tiers, alors je vous suggère de déléguer cette responsabilité au serveur API, ce qui empêchera l'utilisation non autorisée de vos services tiers en votre nom, une fois qu'elle ne servira que des demandes authentiques du mobile Application qui a réussi les défis d'intégrité.
L'API d'attestation SafetyNet vous aide à évaluer la sécurité et la compatibilité des environnements Android dans lesquels vos applications s'exécutent. Vous pouvez utiliser cette API pour analyser les appareils qui ont installé votre application.
Le cadre d'autorisation OAuth 2.0 permet à une application tierce d'obtenir un accès limité à un service HTTP, soit au nom d'un propriétaire de ressource en orchestrant une interaction d'approbation entre le propriétaire de la ressource et le service HTTP, ou en permettant à l'application tierce d'obtenir l'accès pour son propre compte. Cette spécification remplace et rend obsolète le protocole OAuth 1.0 décrit dans la RFC 5849.
L'épinglage est le processus d'association d'un hôte à son certificat ou clé publique X509 attendu. Une fois qu'un certificat ou une clé publique est connu ou vu pour un hôte, le certificat ou la clé publique est associé ou "épinglé" à l'hôte. Si plusieurs certificats ou clés publiques sont acceptables, le programme contient un jeu de pins (extrait de Jon Larimer et Kenny Root Google I/O talk). Dans ce cas, l'identité annoncée doit correspondre à l'un des éléments du jeu de pins.
Authentification basée sur les jetons
Les jetons Web JSON sont une méthode RFC 7519 ouverte et standard de l'industrie pour représenter les revendications en toute sécurité entre deux parties.
Avertissement: je travaille chez Approov.
Ce problème est quelque chose que les jeux mobiles doivent gérer pour des raisons de revenus, et d'après ce que je peux dire, ils le résolvent en mettant constamment à jour l'application, obligeant l'utilisateur à télécharger et à installer un nouveau patch à chaque fois avant de commencer le jeu. il s'agit généralement d'une petite quantité. Ces correctifs ajoutent également du nouveau contenu au jeu. Les correctifs gèrent également la mise à jour eux-mêmes, donc si une application est modifiée, le correctif échoue.
Donc en théorie (je ne sais pas exactement à quel point cela est précis), vous écrivez essentiellement une application dans une application. L'application interne est l'application qui fait le gros du travail. L'application externe, à chaque démarrage, télécharge un validateur de correctif/intégrité, qui vérifie ensuite d'abord que les applications n'ont pas été falsifiées (généralement via une somme de contrôle), puis corrige l'application interne si nécessaire. C'est similaire à un bootstrap.
Comme mentionné par marstato, ce n'est toujours pas parfait. Par exemple, un attaquant peut rediriger les requêtes vers son propre serveur et installer des correctifs personnalisés de cette façon. Une solution possible consiste à effectuer cette validation d'intégrité avant chaque transaction, mais ce serait plutôt lent.