Sécuriser la communication [Authenticité, confidentialité et intégrité] avec une application mobile ?

Question

Une application Android/Iphone accède aux données de l'application à partir du serveur. [Django-Python]

Comment sécuriser la communication avec l'application mobile ?

Attente : Suffisamment sûr pour les informations sensibles comme les mots de passe, il ne doit pas y avoir de moyen direct de décryptage, sauf par forçage brutal.

Mes exigences :

• Authentification [Seule l'application est autorisée].
• Intégrité [les messages ne doivent pas être modifiés entre les deux].
• Confidentialité [La communication ne doit pas être lisible si elle est reniflée].

Mon effort :

• SSL n'authentifie que le serveur, pas le client.
• Je ne peux pas utiliser un cryptage symétrique [Fournit uniquement la confidentialité].
• La signature numérique n'est pas possible [Manque de confidentialité].
• PGP remplit pleinement ces trois conditions.

Problème :

• PGP exige de stocker les clés dans l'application du client.
• Il semble qu'il n'y ait pas de moyen sûr de sécuriser les clés sur l'application client.
• Si la clé est perdue, alors PGP ou le cryptage symétrique sont tout aussi vulnérables.
• La rétro-ingénierie des clés PGP ou des clés symétriques est tout aussi difficile.
• Dans ce cas, PGP est une charge insensée pour le processeur mobile.
• OAuth est encore une fois inutile, puisqu'il a aussi une clé client.

Alors, comment puis-je/doit-on avancer sur ce sujet ? Comment l'industrie fait-elle face à cette situation ?

Dois-je mettre en œuvre une approche occasionnelle ?

• Utiliser un simple SSL et croiser les doigts ? Puisque l'authentification n'est pas possible si les clés sont volées ? (Seule l'authentification du serveur est possible avec ce système).

Mise à jour :

La conclusion a été d'utiliser AES, car si je peux garder la clé sécurisée, je suis aussi bon que SSL. De plus, je peux changer la clé au fil du temps pour une meilleure sécurité. Contribuez si vous pensez qu'il y a une meilleure solution, lisez l'intégralité du message avant de le poster.

Answer 1

Vous travaillez sur de mauvaises informations. SSL peut absolument authentifier le client, mais ce n'est pas quelque chose qui est fait pour la majeure partie de SSL, car le protocole est (ou, du moins, était) généralement utilisé pour protéger les sites de commerce électronique où l'authentification du serveur était importante, mais où le faire avec le client n'était pas important et/ou pas faisable. Ce que vous voulez faire, c'est utiliser le SSL à authentification mutuelle, de sorte que votre serveur n'accepte que les connexions entrantes de votre application et que votre application ne communique qu'avec votre serveur.

Voici l'approche de haut niveau. Créez un certificat SSL de serveur auto-signé et déployez-le sur votre serveur web. Si vous utilisez Android, vous pouvez utiliser l'outil keytool inclus dans le SDK Android à cette fin ; si vous utilisez une autre plate-forme d'application comme iOS, des outils similaires existent également. Créez ensuite un client auto-signé et déployez-le dans votre application dans un keystore personnalisé inclus dans votre application en tant que ressource (keytool le générera également). Configurez le serveur pour qu'il exige une authentification SSL côté client et qu'il n'accepte que le certificat client que vous avez généré. Configurez le client pour qu'il utilise ce certificat côté client pour s'identifier et n'accepte que le certificat côté serveur que vous avez installé sur votre serveur pour cette partie.

Si quelqu'un/quelque chose d'autre que votre application tente de se connecter à votre serveur, la connexion SSL ne sera pas créée, car le serveur rejettera les connexions SSL entrantes qui ne présentent pas le certificat client que vous avez inclus dans votre application.

Une réponse étape par étape à ce sujet serait beaucoup plus longue que ce qui est justifié ici. Je vous suggère de procéder par étapes, car il existe des ressources sur le web sur la façon de traiter les certificats SSL auto-signés dans Android et iOS, tant du côté serveur que client. Vous trouverez également une présentation complète dans mon livre, Sécurité des applications pour la plate-forme Android publié par O'Reilly.

Answer 2

SSL dispose d'une authentification bidirectionnelle, comme l'ont déjà mentionné d'autres commentateurs. Mais, je ne pense pas que vous devriez même essayer d'authentifier le client, c'est-à-dire l'application. Vous authentifiez uniquement l'utilisateur (propriétaire de la ressource en termes d'Oauth) et non l'agent ou le client.

C'est un fait, les applications mobiles n'ont plus de secret pour personne. Ne mettez donc jamais de certificats/mots de passe sur l'appareil. Le mauvais exemple typique serait d'enregistrer le nom d'utilisateur et le mot de passe dans un keystore système, tel que le trousseau d'IOS. Si l'utilisateur de l'application ne définit pas de mot de passe sur le téléphone, l'ensemble du référentiel est enregistré en texte clair et n'importe qui peut récupérer toutes les informations. Intégrer un certificat dans l'application est presque aussi mauvais car, contrairement à un serveur, le téléphone portable n'est pas enfermé dans une salle informatique. Les gens les perdent.

Sur cette base, vous avez besoin d'une solution basée sur des jetons, afin que l'application n'ait pas besoin de conserver des secrets. Vous transmettez les secrets (identifiants de connexion de l'utilisateur) et les effacez immédiatement de la mémoire. Vous ne devez conserver que le jeton, qui sera de courte durée (expire dans 30 minutes, etc.).

Le flux implicite Oauth 2.0 est conçu pour résoudre ce problème. Cependant, il est loin d'être parfait. Et il y a quelques problèmes fondamentaux avec la spécification Oauth 2.0. En particulier, la mise en œuvre de ce flux exige que l'application utilise UIWebView (navigateur intégré), ce qui en soi peut être peu sûr et constituer une mauvaise expérience pour l'utilisateur. Cela élimine donc pratiquement tous les flux basés sur la redirection. La seule application bien connue qui utilise le flux de redirection OAuth 2 est facebook, et elle est mal faite.

Le flux OAuth 2.0 Resource Owner est une option. Avec ce flux, le niveau de sécurité de l'ensemble de votre système peut être aussi élevé que celui d'une solution B2C, par exemple une solution bancaire en ligne basée sur un navigateur. Cela signifie que toute personne disposant du nom d'utilisateur et du mot de passe sera en mesure d'accéder aux ressources sur le serveur - le même niveau de sécurité pour une solution basée sur un navigateur.

Cependant, vous devez toujours être prudent, comme mentionné précédemment, la spécification OAuth 2 a quelques problèmes fondamentaux - dans ce cas, vous ne pouvez pas suivre sa spécification pour mettre en œuvre la logique de rafraîchissement du jeton - qui implique généralement l'utilisation d'un jeton de rafraîchissement sans expiration - qui peut être considéré comme l'implémentation OAuth 2 de Google. Ce jeton devient alors lui-même un secret, ce qui va à l'encontre de l'objectif de l'utilisation d'OAuth.

Une solution de contournement consiste à renouveler automatiquement le jeton en fonction de la dernière activité.

Quoi qu'il en soit, la sécurité des applications mobiles n'est pas un sujet nouveau, mais malheureusement, nous ne disposons toujours pas d'outils/mécanismes standard pour résoudre ces problèmes uniques.

C'est la raison pour laquelle les banques paient des millions de dollars pour leur solution bancaire mobile, mais échouent toujours. http://hothardware.com/News/Mobile-Banking-Apps-for-iOS-Vulnerable-to-Man-in-the-Middle-Attacks/ ) ;-)

Answer 3

Utilisez l'authentification client avec SSL ou superposez simplement votre propre authentification client (nom d'utilisateur/mot de passe, jeton, etc.) à l'authentification serveur SSL.

(Edit : Déplacement du commentaire ici, puisqu'il ne tient pas en tant que commentaire)

Pour développer un peu, toute information d'authentification doit être stockée ou saisie dans l'application. Si vous demandez aux gens de saisir le mot de passe à chaque fois, vous n'avez pas besoin de le sauvegarder, mais c'est clairement peu pratique. Vous pouvez le crypter à l'aide d'une clé spécifique à l'appareil, afin qu'il ne soit pas visible sur les appareils enracinés. Avec une clé privée, vous devez soit la protéger avec un mot de passe saisi par l'utilisateur (voir ci-dessus), soit la faire protéger par le système. Cela n'est possible que depuis Android 4.0 (ICS) avec l'API publique du magasin de clés du système, le KeyChain classe. Dans ce cas, l'utilisateur doit déverrouiller (à l'aide d'un motif/mot de passe ou d'un code PIN) le téléphone pour accéder au keystore.