10

I want to preface this question with two things so I can narrow down where my actual question is:

a) I've done software dev before, though never for android

b) I'm familiar with PKI and encryptions and hashing and digital signatures and blah blah blah

That being said I'm having trouble tracking down more information about where and how Android verifies app creators. I've heard a lot of different information so I'm trying to synthesize to get a better idea of the workflow.

I know that every app developer gets their own private/public key pair and they sign their apps by hashing the APK (with SHA-1 most of the time if I'm not mistaken) and there you go. You upload it and (I believe) the public key goes in META INF inside the APK. This much I understand.

My question is how this relates to when a user downloads the app itself. I know the phone checks to make sure that the app is validly signed, and that the signature also has information about author and etc included. But I've also read that apps are self signed and that Google Play (or whatever they're calling the Market now) doesn't implement a CA, and that there's no identity authentication? But my question is what, then, stops people from uploading an app under another developers name (crowdsourcing aside)?

If the phone only checks for valid signatures does that imply that the only means of authentication is done when the app is uploaded? And if that's the case how does the app market check it? Is it the usual - use the private key on file and verify the signature? Or does the developer have to provide the market with their private key to authenticate?

Fewmitz
  • 487
  • 1
  • 5
  • 21
  • When you sign the apk you have to provide the private password. So in order for someone to post an app "as someone else" They would need access to their keystore / key files and passwords. And access to the Google Account that is linked to the market. – FoamyGuy Jun 07 '12 at 19:17
  • @Tim: I think he is asking: What is to prevent someone else from creating their own keypair and a self-signed certificate that also says "Fewmitz" in it. Is it somehow linked to an account somewhere? – President James K. Polk Jun 07 '12 at 22:36

2 Answers2

12

In short, Android and Google Play essentially don't care about what's in actual certificate. Google Play will validate it indeed, and check if it is valid for 30 years or more, but they don't really use (at least currently, AFAIK) the actual info in the cert. You could use your own name/company name in the CN, but no one will validate this, and users won't see this info at all. What Android does is:

  • check the signature to make sure the APK hasn't been tampered with
  • then compare the singing certificate as a binary blob to the one of the currently installed version of the app to make sure that the two versions have been signed with the same key/certificate (e.g., by the same person/company)
  • it does the same thing to enforce permission if you are using using sharedUid or signature permissions with two or more apps.

So, to answer your question, someone can easily create a certificate with your name on it, but Android and Google Play don't really care. As long as they don't have your private key, they won't be able produce an app signature that is the same as yours and thus they wouldn't be able to overwrite/update your app with theirs, or get any special permissions.

Nikolay Elenkov
  • 52,576
  • 10
  • 84
  • 84
  • So, does that mean that if use two certificates with the same public-private key pair but different subject names, they both would be valid? Basically when I sign my app with my private key, are my details like subject name etc taken into account anywhere? – Ashwin Nov 20 '12 at 13:55
  • 2
    It doesn't care about the actual 'details' (certificate DN, serial number, etc.), but just compares the certificates as binary blobs. Since they are different, you can't update an app originally signed with cert1 with another signed with cert2. – Nikolay Elenkov Nov 20 '12 at 14:04
  • By saying "It doesn't care about the actual 'details' (certificate DN, serial number, etc.)," do you mean that those details are never used? Because ultimately as you yourself told "compares the certificates as binary blobs" - that means it takes the certificate details into account. – Ashwin Nov 20 '12 at 14:07
  • Of course it means no such thing. Think `memcmp()` or `Arrays.equals()`. Do those take certificate details into account? – Nikolay Elenkov Nov 20 '12 at 14:11
  • yeah ok. So the certificates are compared, but the details are never used(other than for comparison) right? Thanks:) – Ashwin Nov 20 '12 at 14:30
  • You can argue semantics if you want, but 'details' implies parsing, which Android doesn't. So no, the details are not used at all. Go read the code if you are not convinced. – Nikolay Elenkov Nov 20 '12 at 14:44
  • 1
    Pretty late but still I think my doubt is valid. What if the the user extends the validity of his private key and signs with that? Will this be accounted if the system compares it as Binary BLOBs? – gnuanu Aug 04 '14 at 11:15
0

Regarding apps updates without using APK signing key rotation - the publisher's whole certificate must be exactly the same for the old and the new version. It was discussed here.

keypress
  • 759
  • 9
  • 12