Android Question How does secure inter-app communication work?

Many bad things can happen if you assume that the OS itself is insecure. For example it can record all the keystrokes or record the screen.
You cannot implement a secure solution on a non-secure OS. If the OS wants to steal all the device data then it will be capable of doing it.

If you create a socket connection between two apps then other apps cannot monitor the connection. You do need to somehow identify the two apps and make sure that you are not connected to a malicious app.

Another approach is to avoid sending sensitive information. For example when you log in to this forum your password is never sent to the server. Only a hash of the password is sent.

Erel said:

You cannot implement a secure solution on a non-secure OS.

Click to expand...

Yep, agreed. Thus all the discussions out there on the net on how important it is with open source firmware and bios and the like.

Erel said:

If you create a socket connection between two apps then other apps cannot monitor the connection.

Click to expand...

We're assuming a non-rooted device here, right? In that case, ok, that does make sense.

Erel said:

You do need to somehow identify the two apps and make sure that you are not connected to a malicious app.

Click to expand...

We're going off into real implementation details here, but I'm wondering if this solution would make sense or if it's just stupid:

Assumptions:
We have two apps, a client app (like the bank app) and an ID app (like the BankID app). There only exists a small, limited amount of client apps, and that they are all known by the BankID organization. The BankID app contains the package names for all the client apps. (Or it looks them up online, not really important for this discussion.)

• The client makes an explicit intent to the ID app together with its request and its own package name.
• The ID app verifies that the client package name is in list of approved, known clients.
• The ID app then sends the response as another explicit intent to the specified package name, together with extra data.

Would this be enough to create secure IAC?

Erel said:

Another approach is to avoid sending sensitive information. For example when you log in to this forum your password is never sent to the server. Only a hash of the password is sent.

Click to expand...

I'm not entirely sure I understand this. I mean, if someone would get hold of my cookie with the password, they'd be able to access to forum as me. Right? The hash is the sensitive information in itself. It doesn't provide any extra security above the fact that they don't actually know my password. (And this is why many sites require you to re-enter your password if you are about to do something extra dangerous, like terminate your account etc, just to make sure it's not a copied cookie/hash.)

Sandman said:

We're assuming a non-rooted device here, right?

Click to expand...

Probably yes.

There is no simple way to verify the identity of the app that sent the intent. Also remember that a hacker can create an app with the same package name and send the intent.

Sandman said:

I mean, if someone would get hold of my cookie with the password, they'd be able to access to forum as me

Click to expand...

You can use password noncing to prevent replay attack: https://stackoverflow.com/questions/8174131/what-is-the-difference-between-hash-salting-and-noncing

Erel said:

There is no simple way to verify the identity of the app that sent the intent.

Click to expand...

Yeah, I think I've read that in the forum. That's why in my example the client added an extra field with its own package name so that the ID app knew where to send its response.

Erel said:

Also remember that a hacker can create an app with the same package name and send the intent.

Click to expand...

You don't mean via the app store, right? In there they all need to be unique, I think. But assuming I haven't installed the official Facebook app, I would be able to whip up an app in B4A using the package name com.facebook.katana (same as Facebook app) and then be eligable for responses from the ID app. That's what you mean, right?

So perhaps intents aren't a good fit for secure communication. And using sockets wouldn't really improve anything at all, right? Just same complexity, but different communication method?

I'm starting to think that the bank app and the BankID app don't have any sensitive exchange at all. Perhaps it's more like this:

• Bank app connects to its backend and informs its waiting for confirmation of my identity
• Bank backend communicates with BankID backend, informing "Bank App For MegaBank" is requesting my identity
• Bank app launches BankID app
• BankID checks with its backend to see if there's a waiting request for identification
• BankID finds waiting request, asks me to enter password and sends that somehow to its backend
• BankID backend verifies my identity and sends an OK to bank backend, which in turn gives thumbs-up to bank app
• Bank app is logged in and ready to be used

Using this flow it's a super simple IAC between the apps, it's basically just an explicit intent to launch the BankID and then BankID returns once there's a success or fail of some sort. It's up to either app to solve the security between itself and its backend.

Makes sense, doesn't it? Would you say it's probably done something like this?

Erel said:

You can use password noncing to prevent replay attack

Click to expand...

But that would only be completely secure if you updated the nonce for every request, isn't that correct? If you "just" limit it to a time window, it's the same as having a vanilla hash, you just have a tighter window of potential (mis-)use. Taking a quick look at the cookies here, it seems posting my nonce would give people a five hour window to use my identity? (assuming I don't do anything before somebody else, thus invalidating the posted value)

Sandman said:

You don't mean via the app store, right?

Click to expand...

No. Package names in the app store are unique.

Sandman said:

I would be able to whip up an app in B4A using the package name com.facebook.katana (same as Facebook app) and then be eligable for responses from the ID app. That's what you mean, right?

Click to expand...

Yes.

Sandman said:

Makes sense, doesn't it? Would you say it's probably done something like this?

Click to expand...

It makes sense. Hard to say how they implemented it.

Sandman said:

But that would only be completely secure if you updated the nonce for every request, isn't that correct?

Click to expand...

You need to implement it as part of the handshake process. It would be unique for each session.

Thanks Erel