java - 验证 Android 代码签名

Question

我们正在计划对 CI 设置进行一些更改，其中包括对用于签署 Android 应用程序的 keystore 进行一些更改(更改密码、 key 别名之类的事情)。

显然，这里的任何错误都可能导致我们使用错误的 key 进行签名，如果它被插入商店，那将是一场灾难。

所以我的问题是:

1. 验证 key 用于签署 Android 应用的最佳方式是什么？
2. 是否可以验证两个应用是否已使用同一 key 进行签名？
3. Google Play 开发者控制台是否有任何保护措施来检测现有应用的 key 更改？

Answer 1

我将以相反的顺序执行此操作:

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

是的，确实如此。事实上，一旦您上传了签名* APK，您就只能提交使用同一证书签名的更新 APK。如果不这样做，Google Play 将会输出如下内容:

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"表示使用非调试证书签名。

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

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

是的。您可以使用 jarsigner或keytool为了这。我更喜欢后者的输出:

keytool -list -printcert -jarfile MyApp.apk

除了一些其他详细信息之外，您还将看到证书的指纹(默认情况下为 MD5、SHA1 和 SHA256)，其看起来有点像这样:

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

您可以对多个 APK 执行此操作并比较结果。或者，您还可以直接将 APK 中的指纹与 keystore 中的证书进行比较:

keytool -list -keystore MyApp.keystore 

输入 keystore 的密码后，您将看到类似以下内容:

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

这应该与 APK 中的 SHA1 指纹完全匹配。

有关如何使用 jarsigner 执行类似操作的示例可以在 one of the answers 中找到。参见上面链接的问答。

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

不确定是否可以客观地回答这个问题，但上述任何一种方法都应该可以解决问题。理想情况下，您需要设置一个脚本来自动执行此检查(作为构建过程的一部分？)并尽早失败，以防发生意外情况。最坏的情况是，您最终会得到一个使用您无意签署的证书签名的 APK。如果此 APK 是现有应用的更新，Google Play 将阻止您提交它。如果它是一个全新的应用程序，则不会，并且它的任何更新都必须使用相同(错误)的证书进行签名。