了解 Android App 认证答案

【问题标题】：Understanding Android App certification了解 Android App 认证
【发布时间】：2015-10-15 10:11:17
【问题描述】：

我正在慢慢了解 Android 应用签名这一主题，但我理解的每一步都只会引出一个进一步的问题。到目前为止我所了解的（我应该提到我的最终目标是在无头 Ubuntu 服务器上自动化 Phonegap 构建，因此我在下面编写的所有内容都使用 Phonegap CLI）

密钥库是一系列私钥-公钥对，每个密钥对都有自己的密码保护。整个密钥库也有自己的密码。 public 密钥 IS 是嵌入在 APK 中的证书。可以按如下方式检查 APK 中使用的证书

解压APK（毕竟是ZIP压缩包）
获取 META-INF/CERT.DSA 文件
keytool -list -file /path/to/CERT.DSA 显示证书指纹。

生成公私密钥对很容易。它甚至可以通过发出一个简单的自动实现

echo y | keytool -genkeypair -dname "cn=com.example, ou=OrgUnitName, o=Org Name, c=US" -alias ANY -keypass aliasPwd -keystore /path/to/keystore -storepass keyStorePwd -validity days

我用Phonegap 构建了一个release apk，通过短信向自己发送了一个指向它的链接，下载并安装了该APK。我的手机给了我一些警告，然后安装了我的 APK。酷！。

但这让我想知道......我创建了第二个别名

echo y | keytool -genkeypair -dname "cn=com.microsoft, ou=Microsoft Mobile, o=Microsoft, c=US" -alias msft -keypass msftPwd -keystore /path/to/keystore -storepass keyStorePwd -validity 9999

这次我使用 Microsoft 别名重建了 APK，给自己发送了一个链接，然后下载并安装了它（我在这里跳过了一些安装细节）。我的 Android 手机再次给了我一些警告，但似乎并没有过分担心我声称自己是 Microsoft。

我不明白。从我在 Android 世界中读到的内容来看，使用自签名证书是一种常见的做法。所以我完全可以伪装成 microsoft.com 或其他任何人？

Android Developer docs 状态

您应该在应用程序的预期生命周期内使用相同的证书签署所有应用程序。

如果有一天我将我的某个应用的权利出售给其他人会怎样？这要么会有效地迫使买家重新开始使用新的 Android 应用程序，要么我将不得不向他们出售所有东西，而不仅仅是一个应用程序？

显然，以上都是正在有效处理的漏洞。但是，我完全不清楚处理它们的措施可能是什么。我将非常感谢任何能够解释我的理解和推理存在缺陷的人。

【问题讨论】：

标签： android cordova apk android-keystore

【解决方案1】：

所以我完全可以伪装成 microsoft.com 或其他任何人？

这是一个自签名证书。没有人注意您在生成证书时使用的值，更不用说相信它们了。

Android 开发者文档指出：“在应用程序的预期生命周期内，您应该使用相同的证书对所有应用程序进行签名。”

按照措辞，我不同意这种评估。在每个应用程序的预期生命周期内，每个应用程序都需要使用相同的证书进行签名。多个应用程序是否由同一个证书签名是一项业务决策，与技术决策一样重要。

如果有一天我将我的某个应用的权利出售给其他人会怎样？

嗯，是吗？

这要么有效地迫使买家重新开始使用新的 Android 应用程序，要么我将不得不向他们出售所有东西，而不仅仅是一个应用程序？

这就是为什么，如果您预计这可能是您想要做的事情，您会为每个应用使用单独的证书。例如，顾问绝对应该为每个应用（或每个客户至少一个）制作一份证书。

相反，如果您正在构建一套应用程序，特别需要它们之间安全通信，您可以考虑为该套件中的所有应用程序使用一个证书。业务后果是您需要将整个套件的权利出售。

【讨论】：

好的。但是，安全性在哪里？在浏览器世界中，人们依赖于能够将 SSL 证书跟踪到可以信任的已知 CA。总的来说，浏览器充当看门狗，并提醒用户注意潜在风险。 self-signed cert. Nobody pays attention 那么谁在保护倒霉手机用户的利益呢？
@DroidOS：自签名证书有两个平台用途。首先，平台可以确定 App A 和 App B 是否使用证书签名，在这种情况下，它们将比使用不同证书签名的两个应用程序有更大的合作机会（因此可能来自不同的开发人员）。其次，如果 App A 是由与 平台本身 签署的相同证书签署的，那么在这种情况下，App A 可以拥有普通应用程序无法拥有的某些权限（例如，重新启动设备）。跨度>
@DroidOS：应用程序还可以检查另一个应用程序证书的公钥部分，主要是查看它是否与已知值匹配。否则，这些自签名证书的安全性与任何使用自签名证书的安全性差不多。例如，对于 Web，自签名证书非常适合启用 SSL 加密，但对于建立真实世界的身份或与某些域的联系无用，这就是浏览器在遇到此类证书时警告用户的原因。
谢谢。你已经澄清了许多问题，但这反过来又引发了其他问题。我的理解是 certificate 是公钥。因此，顾问类型不能简单地使用包含用于不同客户端的多个密钥对的一个密钥库，因为他不能只是放弃该密钥库 - 如果我理解正确，则永远无法重新创建 SAME 密钥。所以他/她应该为每个客户提供一个密钥库？
@DroidOS：“所以他/她应该为每个客户端拥有一个密钥库？” - 是的。 “因此，顾问类型不能简单地使用包含用于不同客户的多个密钥对的一个密钥库，因为他不能只是放弃那个密钥库”——keytool 可能有办法提取一个密钥对到它自己的密钥库中。我从来没有去寻找它，但这似乎不是不可能的。话虽如此，我在一开始就为每个客户设置了单独的密钥库。