In general, these may help: https://www.isecpartners.com/files/iSEC_Securing_Android_Apps.pdf
(perhaps the "Binder Interfaces" section?) https://www.isecpartners.com/intent_sniffer.html On Sat, Jul 10, 2010 at 1:16 PM, Raj <[email protected]> wrote: > thanks for the replies people.. but i'm afraid none of the above > solutions work for my scenario. I thought i could spare all your time > by not bothering you with a lengthy post, but i guess in this case i > will have to explain a bit more to find the answer to my question. > Please bear with my lengthy post....I would really appreciate your > thoughts on some of the problems/questions I have. > > I'm trying to develop a password store application which can store the > username/password (u/p) of the user for the different applications > installed on the phone. So far, most of the password stores I have > seen for Android (including Google's "Secrets for Android" > application) are simple password stores where the user stores the u/p > per application and can transfer it to the respective applications by > copying it to the clipboard. I'm aiming for a solution where the > applications themselves can store the u/p at the password store and > retrieve them automatically when needed. This calls for IPC. The OI > Safe project (http://www.openintents.org/en/safe) attempts something > similar but they send the u/p in clear text in the intents to the > store and there is no authentication of the applications that are > communicating with each other. > > So I need some way of ensuring that > 1)applications on both ends of the communication link are talking with > the correct partner. > 2)data transported between applications in the Intents are safe. i.e. > no other application can intercept and get the intent > > For (1) if I read the documentation correctly, Android offers the > following methods: > i)Signature based permission: This means that only applications signed > with the same private key can communicate with each other. > This method falls short if applications developed by different > developers need to talk with each other. > > ii)custom permissions defined by the application developer: In this > method any application can request this custom permission and if > allowed by the user during install time, can send intents to the > permission declaring application. The only thing the intent receiving > application can do afaik, is to check if the application that sent the > intent was indeed granted this custom permission by the user. There is > no way of checking the "identity" of the application sending the > intent. Another problem is that any application can set an intent > filter for receiving intents directed at this custom permission and > intercept the intent. (I'm assuming that the custom permissions cannot > be kept secret within a group of applications - is this). Even > assuming that the custom permissions can be kept secret, if we want > open access to our application, then the permissions should be > published. > > iii) we can use certificate based authentication, but this means that > the applications have to store the private key in a keystore protected > by a password. The user should supply this password, since fixing the > password in code is not secure. But then, this won't help much for > what i want to achieve. The user will have remember the keystore > passwords for all the applications which in turn will store the u/p in > my password store. On the other hand if Android itself offers a > keystore to which access is granted based on a unique identity of the > application, then the private key can be stored securely. But this > obviates the need for my password store since the applications > themselves can securely store the u/p in the keystore. :-( > Afaik, Android does not offer such a keystore to the installed > applications. > > For (2), sending data in clear text can be solved by encrypting the > data in the intent. Doing a Diffie–Hellman (DH) between the apps can > solve this problem, but DH is prone to MIM attacks, so we are back to > (1). If we dont do encryption, a malicious application having the > GET_TASKS permission will be able to get the base intent (ref: > security whitepaper from Jesse Burns: > https://www.isecpartners.com/files/iSEC_Securing_Android_Apps.pdf) > > My current setup is as follows: > > 1. I use DH for transporting data between the client and the server in > the intents for the first time. I also get a symmetric key in the DH > channel and store it at the client side for future communication with > the server. I dont know how to protect this key without getting > another password from the user (this will defeat the entire purpose of > the password store!). I'm currently relying on the protection offered > by Android i.e. data is private to the application that created it. > But i guess this is not foolproof security.(How to tackle this?) > 2. The data at the server side is stored encrypted with a master key > which in turn is encrypted using a password derived from the one the > user enters at the server side. > 3. I use nonces to ensure that no replay attacks are possible between > the client and the store. > > One way an attacker could break the security is to play MIM during the > DH run, which i think is a bit hard. Another way is to get hold of the > symmetric key stored inside the client application and use it to get > the stored u/p from the store. This is where I think a method that > would help the server to get the "identity" of the application sending > the intent from the Android OS will greatly help. The server can check > this against the one received when the original application save the u/ > p. This "identity" needs to be something unique that the application > cannot fake and that can be reliably reported by Android. I thought > the applications' "package name" would be a good candidate since I'm > under the impression that no two applications will have the same > package name. Hence my original question in this thread to know how to > get hold of this info. Or is there any other way to solve the problem > of client authentication? > > Thanks for reading! Any help is greatly appreciated. :-) > > On Jul 10, 9:13 pm, Dianne Hackborn <[email protected]> wrote: >> On Sat, Jul 10, 2010 at 4:47 AM, Raj <[email protected]> wrote: >> > So I need to know the "identity", which i think in Android's case is >> > the package name with which the clients are installed (I'm assuming no >> > two applications will be allowed to be installed with the same package >> > name in Android - is this correct?). >> >> Package name is NOT a secure identity. Only one package with a given name >> can be installed, but nothing prevents someone from writing another package >> with the same name and installing it -instead-. >> >> The global secure identity for an app is its package name + signing cert. >> >> For purely running on a particular device, the uid is the security sandbox >> level, so the only thing you need to deal with to ensure security. The only >> thing you'd need to take care of is remove information about a uid when it >> gets uninstalled (There's a Broadcast For That(tm)), so that when a new app >> gets installed with that same (no longer used) uid you don't confuse it with >> the old app. >> >> -- >> Dianne Hackborn >> Android framework engineer >> [email protected] >> >> Note: please don't send private questions to me, as I don't have time to >> provide private support, and so won't reply to such e-mails. All such >> questions should be posted on public forums, where I and others can see and >> answer them.
