Android apk签名原理

一、什么是apk签名

签名是摘要与非对称密钥加密相相结合的产物，摘要就像内容的一个指纹信息，一旦内容被篡改，摘要就会改变，签名是摘要的加密结果，摘要改变，签名也会失效。Android APK签名也是这个道理，如果APK签名跟内容对应不起来，Android系统就认为APK内容被篡改了，从而拒绝安装，以保证系统的安全性。

应用程序的作者使用自己的私钥签名APK文件，并将签名与公钥一起发布到APK中，这个过程称之为签名。当应用程序被安装时，用发布的公钥去解析签名，并与文件的hash进行比对，这个过程叫验签。

二、为什么需要签名

在消息通信时，必须至少解决两个问题：一是确保消息来源的真实性，二是确保消息不会被第三方篡改。

签名机制主要有两种用途：

• 使用特殊的key签名可以获取到一些不同的权限
• 验证数据保证不被篡改，防止应用被恶意的第三方覆盖

三、apk签名方案

Android 现在已经支持三种应用签名方案：

• v1 方案：基于 JAR 签名。
• v2 方案：APK 签名方案 v2，在 Android 7.0 引入。
• v3 方案：APK 签名方案v3，在 Android 9.0 引入。
• v4 方案：APK 签名方案v4，在Android11.0引入。

v1 到 v2 是颠覆性的，为了解决 JAR 签名方案的安全性问题，而到了 v3 方案，其实结构上并没有太大的调整，可以理解为 v2 签名方案的升级版，有一些资料也把它称之为 v2+ 方案。因为这种签名方案的升级，就是向下兼容的，所以只要使用得当，这个过程对开发者是透明的。

v1 到 v2 方案的升级，对开发者影响最大的，就是渠道签署的问题。在当下这个大环境下，我们想让不同渠道、市场的安装包有所区别，携带渠道的唯一标识，这就是我们俗称的渠道包。好在各大厂都开源了自己的签渠道方案，例如：Walle（美团）、VasDolly（腾讯）都是非常优秀的方案。

1.V1签名

在 META-INF 文件夹下有三个文件：MANIFEST.MF、CERT.SF、CERT.RSA。

(1).MANIFEST.MF

该文件中保存的内容其实就是逐一遍历 APK 中的所有条目，如果是目录就跳过，如果是一个文件，就用 SHA1（或者 SHA256）消息摘要算法提取出该文件的摘要然后进行 BASE64 编码后，作为「SHA1-Digest」属性的值写入到 MANIFEST.MF 文件中的一个块中。该块有一个「Name」属性， 其值就是该文件在 APK 包中的路径。

(2).CERT.SF

SHA1-Digest-Manifest-Main-Attributes：对 MANIFEST.MF 头部的块做 SHA1（或者SHA256）后再用 Base64 编码
SHA1-Digest-Manifest：对整个 MANIFEST.MF 文件做 SHA1（或者 SHA256）后再用 Base64 编码
SHA1-Digest：对 MANIFEST.MF 的各个条目做 SHA1（或者 SHA256）后再用 Base64 编码

(3).CERT.RSA
这里会把之前生成的 CERT.SF 文件，用私钥计算出签名, 然后将签名以及包含公钥信息的数字证书一同写入 CERT.RSA 中保存。这里要注意的是，Android APK 中的 CERT.RSA 证书是自签名的，并不需要这个证书是第三方权威机构发布或者认证的，用户可以在本地机器自行生成这个自签名证书。Android 目前不对应用证书进行 CA 认证。

V1的签名和校验过程如下：

2.V2签名

v1 签名有两个地方可以改进：

• 签名校验速度慢。校验过程中需要对apk中所有文件进行摘要计算，在 APK 资源很多、性能较差的机器上签名校验会花费较长时间，导致安装速度慢。

• 完整性保障不够。META-INF 目录用来存放签名，因此该目录本身是不计入签名校验过程的，可以随意在这个目录中添加文件，比如一些快速批量打包方案就选择在这个目录中添加渠道文件。

3.V3签名