Android De Stockage Sécurisé

Je veux stocker certains petits mais pièce essentielle de l'information tels que des clés AES dans mon application Android. Quelle serait la méthode recommandée pour ce faire? Je ne veux pas coder en dur des clés dans le cadre de ma demande.

Je regarde Fichier de clés mais il ne résout pas vraiment mon problème. Il peut stocker mes clés étant donné que je peux fournir un mot de passe. Alors j'ai besoin de trouver un endroit sûr pour stocker ce mot de passe qui est la même que mon problème d'origine.

Est-il intégré dans Android classe pour effectuer cette tâche? Ou dois-je regarder pour les bibliothèques tierces? À l'aide de NDK est également acceptable pour moi.

Mise à jour:

J'espérais trouver une API Android pour le stockage, telles que les garanties que seule l'application stockée certaines informations peuvent les récupérer en arrière. Android OS pourrait avoir appliqué cette reposant sur la signature signatures de l'application. De cette façon, ma demande peut générer une clé aléatoire lors de la première exécution et de le stocker dans un endroit sûr pour une utilisation ultérieure. Existe-il une API pour cela?

  • Eh bien, si vous stockez des données dans l'application /data/data/<packagename>/ alors seulement que l'application peut accéder. Ce n'est pas vrai si le téléphone est enracinée si. Mais autre que cela, vous devriez être ok stockage de données de mot de passe il.
InformationsquelleAutor Szere Dyeri | 2010-07-27
  1. 5

    Est-il intégré dans la classe pour Android
    effectuer cette tâche?

    Autres que java.io.File, no.

    Ou dois-je regarder pour des tiers,
    les bibliothèques?

    Vous pouvez essayer, mais je soupçonne la plupart des ressemblera la solution que vous avez déjà rejeté. La plupart des données sécurisées magasins impliquer les mots de passe et d'en assumer les mots de passe sont détenus ailleurs (par exemple, un utilisateur de la tête). Par exemple, OI Sûr a l'Intention d'un système d'permettant d'applications pour stocker des trucs dans le coffre, mais ensuite, l'utilisateur est impliqué dans l'ouverture du coffre-fort, IIRC.

    • Merci pour la réponse. Il ne résout pas vraiment mon problème, mais il est bon d'en connaître les limites.
    • Dyeri: "j'espérais trouver une API Android pour le stockage, telles que les garanties que seule l'application stockée certaines informations peuvent les récupérer en arrière." -- il n'y a pas une telle API Android, désolé.
    • Que voulez-vous dire il n'y a pas une telle API? Cette garantie est le comportement par défaut pour tous les fichiers de l'application des magasins de stockage interne, étant donné que chaque application est donné un IDENTIFIANT d'utilisateur unique et à la mode par défaut des fichiers d'une application crée est uniquement accessible en lecture/écriture par le créateur du uide. La seule exception à cela est (a) placer les fichiers sur le stockage externe, et (b) les fichiers créés avec le drapeau de leur faire monde accessible en lecture/écriture. La seule façon d'une autre application peut s'exécuter avec votre uid est si à la fois (a) il est signé avec votre cert et (b) vous avez tous les deux le même android:sharedUserId.
    • J'étais sous l'impression que l'OP a été la recherche de quelque chose qui pourrait survivre à un dispositif enracinée. Votre solution, bien que tout à fait à propos sinon, peut-être trivialement vaincu par l'enracinement. Cependant, une racine-la preuve de la solution est certainement une hypothèse de la mienne, et je m'en excuse à l'OP, si l'enracinement n'est pas une source de préoccupation particulière.
    • Ah, si l'utilisateur a la racine, il n'y a pas de données, vous pouvez le protéger, période à la fin de l'histoire. Vous pouvez essayer de rendre les choses plus difficiles, mais la protection réelle est allé.
    • En supposant que vous êtes prêt à accepter la mise en réseau des exigences de l'application, vous pouvez exécuter un simple magasin de clés (device-id) sur un serveur et d'assurer le protocole HTTPS est utilisé pour récupérer cette clé au démarrage? Ensuite, il y a de la récupération d'urgence des problèmes et (modifier?) l'échelle des préoccupations?
    • Est-ce toujours le même après 3 ans?
    • Oui. Le stockage interne est protégée contre les autres applications, mais pas contre dispositif enracinée utilisateurs.
    • Selon ce que j'ai lu sur le sujet, si l'attaquant peut renverser l' .apk (même une obfuscation d'ailleurs, malgré la difficulté supplémentaire), la récupération de clé de requête HTTPS peut être compris et de simulation dans le but d'acquérir la touche de la télécommande.
    • Ce n'est pas vrai. Bien que les puces ARM pourrait pas le supporter. Avec des frites qui prennent en charge les spécifications du Trusted Computing Group vous pouvez créer une clé privée qui ne peut être accessible par code avec une certaine hachage. C'est le travail de la matériel pour assurer cette protection est en place, et l'enracinement de l'appareil ne change pas cela. Il est donc techniquement possible, mais je ne sais pas si les puces ARM mettre en œuvre cette technologie.

    InformationsquelleAutor CommonsWare
  2. 4

    Une solution, si vous vous retrouvez avec l'aide du fichier de stockage des clés API, est de générer votre mot de passe dynamiquement lors de l'exécution à chaque fois que l'application a besoin d'accéder au fichier de stockage des clés. Si vous basez votre mot de passe de l'algorithme sur un simple, mais changeant, variable liée à l'installation spécifique comme l'appareil MEID (ou une autre ID du périphérique physique acquise au moment de l'exécution), vous pouvez fournir une clé pour la serrure qui devient de plus en plus difficile à ramasser.

    Exemple: utilisation d'un IDENTIFIANT à partir de la physique de l'appareil, couper en trois positions et de les ajouter à la fin de la position dans la chaîne de l'ID, puis ajouter vos initiales à la chaîne de la programmation. Je pense que cette approche permettrait de donner une couche de sécurité qui ne peuvent pas être facilement brisée, si le pirate sait comment vous faites la clé (c'est à dire a votre code source).

    MEID = MEID + "fluffy" + "2008";

    Où MEID est une chaîne de caractères avec une certaine ID de l'appareil, "moelleux" est le nom de vos meilleurs amis chat, et "2008" est l'année d'un événement important dans votre vie. Ensuite nourrir cette nouvelle chaîne en un tableau, d'analyser à travers un certain nombre qui vous convient (le jour du mois que vous avez obtenu votre permis de conduire par exemple), prenez les trois caractères et supprimer ces caractères à la fin de la chaîne. Clip à partir de l'avant de la chaîne pour le nombre de positions que vous avez besoin pour vos clés et vous allez loin. Cela ne devrait pas être un très intensive du processeur tâche donc, avec une certaine tolérance aux pannes code pour les variables, vous devriez être en mesure de l'exécuter dans votre processus principal, même avec trop de soucis de l'obtention de l'ANR à partir du système. Si vous voulez vraiment obtenir froggy, convertir la chaîne de bits à un certain point, et "bit-à-bit op' les modifications. Viola, une faible surcharge, clé dynamique qui est unique à l'appareil il est exécuté sur!

    EDIT:

    Comme @RedWarp souligné, la décompilation d'un .apk est toujours dans le domaine de la possibilité pour n'importe quel objet de code avec les outils appropriés et de la motivation. Si la "clé" de génération est un processus très important alors abstraction de la clé gen en dehors de la portée de l'application est un must.

    Le véritable point que je suis en train de faire avec cette réponse, c'est qu'un peu avant la pensée peut aller de l'une des façons en ce qui concerne la sécurité minimale. Le renforcement de la sécurité est plus en profondeur qu'une simple réponse de moi.

    • La sécurité par l'obscurité ne peut de retard persistant attaquant. Assurez-vous que cela ajoute du piquant à la recette. Il ne devrait pas être utilisé comme seule option viable.
    • Bien sûr, ce n'est pas présentée comme une seule option viable, mais c'est un début, à une à penser à d'autres moyens uniques et en ce qui concerne la clé de sécurité. Mais, si l'application en question est une application financière ou d'autres de haute sécurité de mise en œuvre, ce qui devrait fournir suffisamment d'obscurité. Une autre option pourrait être à distance de fournir les obscurci par le biais d'un RPC script ou quelque chose, mais cette approche comprendra probablement une complexité supplémentaire.
    • Il est très facile à renverser .apk, et à cet effet, obtenir de l'algorithme de
    InformationsquelleAutor Kingsolmn
  3. 0

    Vous avez de distinguer ici entre les clés et les données de l'application.

    La "AndroidKeyStore" KeyPairGenerator et KeyGenerator stocke les clés de générer à partir de votre application sous un alias dans le fichier de clés et associe les clés de votre application. Si l'appareil est "matériel", vous pouvez spécifier qu'elle soit utilisée et les touches y être stockées.

    Il n'y a pas de mot de passe pour les clés. Vous utilisez l'alias de spécifier la clé que vous souhaitez utiliser. Seulement dans votre application peut récupérer les clés qu'il avait engendré.

    voir:https://developer.android.com/training/articles/keystore.html

    Pour votre application à des données privées, si je comprends bien ".. une API Android pour le stockage, telles que les garanties que seule l'application stockée certaines informations peuvent les récupérer en arrière. ..", vous pouvez regarder ces:

    https://developer.android.com/guide/topics/data/data-storage.html#filesInternal
    https://developer.android.com/guide/topics/data/data-storage.html#db

    InformationsquelleAutor