简体   繁体   中英

Verifying Android Code Signing

We are planning some changes to our CI set-up that will involve making some changes to the keystores were using to sign Android applications (changing password, key alias that kind of thing).

Obviously any mistake here that could cause us to sign with the wrong key would be a bit of a disaster if it got pushed in the store.

So my questions are:

  1. What is the best way of verifying the key use to sign an Android app?
  2. Is it possible to verify that two apps have been signed by the same key?
  3. Does the Google Play Developer Console have any safeguards in place to detect a change in key for an existing app?

I'll do this in reverse order:

  1. Does the Google Play Developer Console have any safeguards in place to detect a change in key for an existing app?

Yes it does. As a matter of fact, once you've uploaded a signed* APK, you can only submit updated APKs signed with that very same certificate. Failing to do so will make Google Play spit out something like:

Upload failed

You uploaded an APK that is signed with a different certificate to your previous APKs. You must use the same certificate.

Your existing APKs are signed with the certificate(s) with fingerprint(s): [ SHA1: 89:2F:11:FE:CE:D6:CC:DF:65:E7:76:3E:DD:A7:96:4F:84:DD:BA:33 ] and the certificate(s) used to sign the APK you uploaded have fingerprint(s): [ SHA1: 20:26:F4:C1:DF:0F:2B:D9:46:03:FF:AB:07:B1:28:7B:9C:75:44:CC ]

  • = "signed" means signed with a non-debug certificate.

Source: The apk must be signed with the same certificates as the previous version

  1. Is it possible to verify that two apps have been signed by the same key?

Yes. You can use either jarsigner or keytool for this. I prefer the output of the latter:

keytool -list -printcert -jarfile MyApp.apk

Amongst a few other details, you'll be presented with the certificate's fingerprints (MD5, SHA1 and SHA256 by default), which looks somewhat like this:

Certificate fingerprints:
     MD5:  12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF
     SHA1: 12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:44
     SHA256: 12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:12:34:56:78:90:AB:CD:EF:12:34:56:78
     Signature algorithm name: SHA1withRSA
     Version: 3

You can do this for multiple APKs and compare results. Alternatively, you can also compare the fingerprints from the APK directly against the certificate in a keystore:

keytool -list -keystore MyApp.keystore 

After entering the keystore's password, you'll see something like:

Certificate fingerprint (SHA1): 12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:44

This should be an exact match to the SHA1 fingerprint from the APK.

An example on how to use jarsigner to do something similar can be found in one of the answers to the Q&A linked above.

  1. What is the best way of verifying the key use to sign an Android app?

Not sure if this can be answered objectively, but either of the methods described above should do the trick. Ideally you'll want to setup a script to automate this check (as part of your build process?) and fail as early as possible in case something unexpected happened. Worst case scenario you'll end up with an APK signed with a certificate you didn't mean to sign it with. If this APK is an update to an existing app, Google Play will prevent you from submitting it. If it's a brand-new app, it will not, and any updates for it will have to be signed with the same (wrong) certificate.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM