应用程序签名

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

应用程序签名允许开发人员识别应用程序的作者并更新他们的应用程序,而无需创建复杂的接口和权限。在 Android 平台上运行的每个应用程序都必须由开发人员签名。尝试在未签名的情况下安装的应用程序将被 Google Play 或 Android 设备上的软件包安装程序拒绝。

在 Google Play 上,应用程序签名连接了 Google 对开发人员的信任以及开发人员对其应用程序的信任。开发人员知道他们的应用程序未经修改就提供给了 Android 设备;开发人员可以对其应用程序的行为负责。

在 Android 上,应用程序签名是将应用程序放入其应用程序沙箱的第一步。签名的应用程序证书定义了哪个用户 ID 与哪个应用程序相关联;不同的应用程序在不同的用户 ID 下运行。应用程序签名确保一个应用程序不能访问任何其他应用程序,除非通过明确定义的 IPC。

当应用程序(APK 文件)安装到 Android 设备上时,包管理器会验证 APK 是否已使用该 APK 中包含的证书正确签名。如果证书(或更准确地说,证书中的公钥)与用于签署设备上任何其他 APK 的密钥匹配,则新 APK 可以选择在清单中指定它将与另一个类似地共享 UID - 签名的 APK。

应用程序可以由第三方(OEM、运营商、替代市场)签名或自签名。 Android 使用自签名证书提供代码签名,开发人员无需外部协助或许可即可生成这些证书。申请不必由中央机构签署。 Android 目前不对应用证书进行 CA 验证。

应用程序还能够在签名保护级别声明安全权限,将访问权限限制为仅使用相同密钥签名的应用程序,同时保持不同的 UID 和应用程序沙箱。通过共享 UID 功能允许与共享应用程序沙箱建立更密切的关系,其中使用相同开发人员密钥签名的两个或多个应用程序可以在其清单中声明共享 UID。

APK 签名方案

Android 支持三种应用签名方案:

为了获得最大的兼容性,请使用所有方案对应用程序进行签名,首先使用 v1,然后使用 v2,然后使用 v3。 Android 7.0+ 和更新的设备安装使用 v2+ 方案签名的应用程序比仅使用 v1 方案签名的应用程序更快。较旧的 Android 平台忽略 v2+ 签名,因此需要应用程序包含 v1 签名。

JAR 签名(v1 方案)

APK 签名从一开始就是 Android 的一部分。它基于签名的 JAR 。有关使用此方案的详细信息,请参阅有关签署您的应用程序的 Android Studio 文档。

v1 签名不保护 APK 的某些部分,例如 ZIP 元数据。 APK 验证者需要处理大量不受信任(尚未验证)的数据结构,然后丢弃未包含在签名中的数据。这提供了相当大的攻击面。此外,APK 验证程序必须解压缩所有压缩条目,消耗更多时间和内存。为了解决这些问题,Android 7.0 引入了 APK 签名方案 v2。

APK 签名方案 v2 & v3(v2+ 方案)

运行 Android 7.0 及更高版本的设备支持 APK 签名方案 v2(v2 方案)及更高版本。 (在 Android 9 中,v2 方案已更新为 v3,以在签名块中包含其他信息,但其他工作方式相同。) APK 的内容经过哈希处理和签名,然后将生成的 APK 签名块插入 APK。有关将 v2+ 方案应用于应用程序的详细信息,请参阅APK 签名方案 v2

在验证期间,v2+ 方案将 APK 文件视为一个 blob,并对整个文件执行签名检查。对 APK 的任何修改(包括 ZIP 元数据修改)都会使 APK 签名无效。这种形式的 APK 验证速度要快得多,并且可以检测更多类别的未经授权的修改。

新格式是向后兼容的,因此使用新签名格式签名的 APK 可以安装在较旧的 Android 设备上(它们只是忽略添加到 APK 中的额外数据),只要这些 APK 也是 v1 签名的。

APK签名验证流程

图 1. APK 签名验证流程

APK 的整个文件哈希根据存储在 APK 签名块中的 v2+ 签名进行验证。哈希涵盖了除包含 v2+ 签名的 APK 签名块之外的所有内容。在 APK 签名块之外对 APK 进行的任何修改都会使 APK 的 v2+ 签名无效。带有剥离 v2+ 签名的 APK 也会被拒绝,因为它们的 v1 签名指定 APK 是 v2 签名的,这使得 Android 7.0 和更新版本拒绝使用它们的 v1 签名验证 APK。

APK签名验证流程详见APK签名方案v2的验证部分