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.
