1

I'm looking at the architecture of Android and want to come up with a service that allows for multiple applications (3rd party) to call a local android service and fetch data. Think of this as a partitioned dropbox service, where each app saves a file, and if the user configures the app to share data between apps (e.g. photos between app1 and app2) then it's permitted.

Are you aware of any API that will allow me to securely validate the calling application so they they are the only ones that can access their store?

I’m thinking about identifying the calling EXE, and checking that hash but that won't work if the app is updated.

Potentially each app is signed by the same key so I can use that as a unique app-identifying constant.

My main concern is someone gaining binary access to app #1, extracting a key or identifier, an using that to spoof access to my Android Service.

Any alternate solutions are welcome

2

So this is a really tough problem, and I don't believe there are any APIs out there to achieve what you want.

What you can't do: Custom Permissions


While they sound like a good idea custom permissions are defined in the AndroidManifest.xml. Checkout this SO answer on how to define/use them, but they look something like this:

<permission 
    android:name="com.testpackage.mypermission" 
    android:label="my_permission" 
    android:protectionLevel="dangerous">
</permission>

To use the permission all another application has to do is put the following in their own AndroidManifest.xml:

<uses-permission android:name="com.testpackage.mypermission"/>

Since Android APKs are trivial to reverse engineer to gain the most basic information about an application; this would fall your fear of someone gaining access to the APK. Anyone with a rooted phone can pull the APK from their phone.

I do admit that there is likely more to using a custom permission than just that XML line. But it seems if someone is going through the trouble to begin with, then they can figure it out.

Solution?


This is a tough problem, because at some point you'll need to ask the user to verify that they trust an application to be used with your core app. If the user verifies that they trust the app then I would probably record the application's signature; which can be found at runtime. If the signature changes from what you have recorded then it's not the application the user trusted.

This is probably the easiest solution. Verifying the signature itself should be possible as the META-INF/CERT.RSA contains the signature and public key to verify the signature. I believe this post on SO shows how this can be done.

Again, you're still relying on the user to verify trust of an application through your core application. I'm not sure if this is acceptable to you or not.

  • This works for me, and might be the best solution. Thank you. Are you aware of any similar approach for iOS apps? – Christopher Aug 7 '15 at 15:53
  • @LamonteCristo Unfortunately I'm not very familiar with iOS development. But a quick search for app verification came up with an SO answer. – RoraΖ Aug 7 '15 at 16:10
  • thanks I'll search some more... that was for OSX (Desktop) not iOS (Phone). I'll poke around. Thanks! – Christopher Aug 7 '15 at 16:12
  • 1
    You could use android:protectionLevel="signature" -- this would limit Intents to applications sharing the same signing key. This works if you're the producer of both apps, but doesn't help if you're not. – Edward Falk Mar 21 '16 at 21:15
  • @EdwardFalk Nice! I didn't know about that attribute. – RoraΖ Mar 22 '16 at 13:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.