CODEWITHSUNDEEP
c#androidxamarin.android
Andras Zoltan
Andras Zoltan

Reputation: 42333

Is there any secure storage in Android through Monodroid out of the box?

Like many people - I am developing an app with a shared codebase (Windows Store + Android + MonoTouch + [later] WP8).

Also, as with many apps, I have local state that I need to persist for this app.

One piece of information I store is an authentication token for the signed-in user. On the Windows Store platform I have implemented the storage of this with a mixture of roaming settings (ApplicationData.Current.RoamingSettings) for the token's ancillary data (user name and issued date) and the PasswordVault for the actual token value. Thus the token is protected from OS-level introspection, because it is encrypted by the OS.

Now I'm implementing the same interface for my MonoDroid build, and I can't see any way, provided by the platform, to store data that can only be decrypted by my application - in the same way as the password vault can be used for Store apps.

As a result, at the moment, I'm simply using the Android.Content.ISharedPreferences interface via the Application.Context.GetSharedPreferences method to read and write these values.

So am I correct in my assumption that the platform (MonoDroid or Android) offers no secure storage OOB? Is the only alternative to implement encryption within the app - which will of course require baking the encryption key into the code? Or can I grab the certificate used to sign the app and use that as a key?

Ultimately it's not the end of the world if I can't encrypt this data, since the token is time-limited anyway - but it would be nice if I could actually do it properly!

Upvotes: 14

Views: 1360

Answers (2)

KennyC
KennyC

Reputation: 961

You could use it with a combination of Keychain API (available in API level 14 onwards) and encrypting the data with Cipher API using the certificate from the Keychain api.

Take note: According to Android Security Overview document, there is no guarantees if the device is rooted: http://source.android.com/tech/security/index.html#rooting-of-devices

Upvotes: 1

Alejandro Colorado
Alejandro Colorado

Reputation: 6094

Maybe this quoting from here can help you:

On the android side OOB is not supported in the public API so things get tricky. I believe this is because Honeycomb 3.2 does not have a bluez stack that officially supports OOB bonding, but Google has some kind of implementation coded in. I believe this because if you look at gingerbread source code for the Bluetooth Adapter and Bluetooth Device classes you can see OOB methods available but not exposed through the documented API.

These methods are still public so you can call them through reflection. Using reflection you can also get all of the method signatures in a class. This is how I figured out what methods I had available to me.

Beware though that many are not documented and it's not obvious what some do. The important ones to make note of are the readOutOfBandData() in the adapter class and setDeviceOutOfandData() in the device class.

Upvotes: 0

Related Questions