Y at-il un stockage sécurisé dans Android via Monodroid out of the box?

Question

Comme beaucoup de gens - je développe une application avec une base de code partagée (Windows Store + Android + MonoTouch + [plus tard] WP8).

En outre, comme avec de nombreuses applications, j'ai l'état local que je dois persister pour cette application.

Une information que je stocke est un jeton d'authentification pour l'utilisateur connecté. Sur la plate-forme Windows Store, j'ai mis en place le stockage avec un mélange de paramètres d'itinérance (ApplicationData.Current.RoamingSettings) pour les données auxiliaires du jeton (nom d'utilisateur et date d'émission) et PasswordVault pour la valeur du jeton réel. Ainsi, le jeton est protégé de l'introspection au niveau du système d'exploitation, car il est chiffré par le système d'exploitation. Maintenant, j'implémente la même interface pour mon build MonoDroid, et je ne vois aucun moyen, fourni par la plate-forme, de stocker des données qui ne peuvent être déchiffrées que par mon application - de la même manière que le mot de passe Vault peut être utilisé pour les applications Store. Par conséquent, pour l'instant, j'utilise simplement l'interface Android.Content.ISharedPreferences via la méthode Application.Context.GetSharedPreferences pour lire et écrire ces valeurs.

Alors, est-ce que j'ai raison de penser que la plateforme (MonoDroid ou Android) n'offre pas de stockage sécurisé OOB? Est-ce la seule alternative pour implémenter le cryptage au sein de l'application - ce qui, bien sûr, nécessitera de cuire la clé de cryptage dans le code? Ou puis-je récupérer le certificat utilisé pour signer l'application et l'utiliser comme clé?

En fin de compte ce n'est pas la fin du monde si je ne peux pas chiffrer ces données, car le jeton est limitée dans le temps de toute façon - mais ce serait bien si je pouvais le faire correctement !

Answer 1

Peut-être cette citation de here peut vous aider:

Sur le OOB côté android est pas pris en charge dans l'API publique si les choses se compliquent . Je crois que c'est parce que Honeycomb 3.2 n'a pas une pile bluez qui prend officiellement en charge OOB bonding, mais Google a un certain type d'implémentation codé po Je crois cela parce que si vous regardez code source gingerbread pour l'adaptateur Bluetooth et Bluetooth Device vous pouvez voir les méthodes OOB disponibles mais non exposées via l'API documentée .

Ces méthodes sont toujours publiques, vous pouvez donc les appeler via . En utilisant la réflexion, vous pouvez également obtenir toutes les méthodes signatures dans une classe. C'est ainsi que j'ai compris quelles méthodes j'avais à ma disposition.

Méfiez-vous cependant que beaucoup ne sont pas documentés et ce n'est pas évident ce que font les autres . Les éléments importants à prendre en compte sont readOutOfBandData() dans la classe de l'adaptateur et setDeviceOutOfandData() dans la classe d'unité.

Answer 2

Vous pouvez l'utiliser avec une combinaison de Keychain API (disponible dans le niveau de l'API 14 et suivantes) et le cryptage des données avec Cipher API en utilisant le certificat du porte-clés api.

Prenez note: Selon le document Présentation Android sécurité, il n'y a aucune garantie si l'appareil est enraciné: http://source.android.com/tech/security/index.html#rooting-of-devices