Android签名V1、V2、V3、V4汇总

目录
一、什么是apk签名？
二、为什么需要签名
三、apk签名方案
V1
V2
V3
四、apk签名校验
五、多渠道打包

前言

消息摘要

消息摘要只能保证消息的完整性，并不能保证消息的不可篡改性。

消息摘要（Message Digest），又称数字摘要（Digital Digest）或数字指纹（Finger Print）。简单来说，消息摘要就是在消息数据上，执行一个单向的 Hash 函数，生成一个固定长度的Hash值，这个Hash值即是消息摘要。
加密 Hash 函数就是消息摘要算法。经典的Hash算法有：MD5 算法、SHA-1 算法、SHA-256，SHA-256 是 SHA-1 的升级版，现在 Android 签名使用的默认算法都已经升级到 SHA-256 了。

数字签名

数字签名方案是一种以电子形式存储消息签名的方法。一个完整的数字签名方案应该由两部分组成：签名算法和验证算法。

几乎所有的数字签名方案都要和快速高效的摘要算法（Hash 函数）一起使用，当公钥算法与摘要算法结合起来使用时，便构成了一种有效地数字签名方案。

这个过程是：

用摘要算法对消息进行摘要。
再把摘要值用信源的私钥加密。

通过以上两步得到的消息就是所谓的原始信息的数字签名，发送者需要将原始信息和数字签名一同发送给接收者。而接收者在接收到原始信息和数字签名后，通过以下 3 步验证消息的真伪：

先把接收到的原始消息用同样的摘要算法摘要，形成「准签体」。
使用预先得到的公钥，将数字签名进行解密。
比较前两步所得到的两段消息是否一致。如果一致，则表明消息确实是期望的发送者发的，且内容没有被篡改过；相反，如果不一致，则表明传送的过程中一定出了问题，消息不可信。

这种方法使公钥加密只对消息摘要进行操作，因为一种摘要算法的摘要消息长度是固定的，而且都比较「短」（相对于消息而言），正好符合公钥加密的要求。这样效率得到了提高，而其安全性也并未因为使用摘要算法而减弱。

综上所述，数字签名是 非对称加密技术 + 消息摘要 技术的结合。

公钥密码体制（public-key cryptography）
公钥密码体制分为三个部分，公钥、私钥、加密解密算法，它的加密解密过程如下：

加密：通过加密算法和公钥对内容（或者说明文）进行加密，得到密文。加密过程需要用到公钥。

解密：通过解密算法和私钥对密文进行解密，得到明文。解密过程需要用到解密算法和私钥。注意，由公钥加密的内容，只能由私钥进行解密，也就是说，由公钥加密的内容，如果不知道私钥，是无法解密的。

公钥密码体制的公钥和算法都是公开的（这是为什么叫公钥密码体制的原因），私钥是保密的。大家都以使用公钥进行加密，但是只有私钥的持有者才能解密。

在实际使用中，有需要的人会生成一对公钥和私钥，把公钥发布出去给别人使用，自己保留私钥。目前使用最广泛的公钥密码体制是 RSA 密码体制。

对称加密算法（symmetric key algorithms）
在对称加密算法中，加密和解密都是使用的同一个密钥。因此对称加密算法要保证安全性的话，密钥要做好保密，只能让使用的人知道，不能对外公开。

非对称加密算法（asymmetric key algorithms）
在非对称加密算法中，加密使用的密钥和解密使用的密钥是不相同的。前面所说的公钥密码体制就是一种非对称加密算法，它的公钥和是私钥是不能相同的，也就是说加密使用的密钥和解密使用的密钥不同，因此它是一个非对称加密算法。

RSA 简介
RSA 密码体制是一种公钥密码体制，公钥公开，私钥保密，它的加密解密算法是公开的。由公钥加密的内容可以并且只能由私钥进行解密，而由私钥加密的内容可以并且只能由公钥进行解密。也就是说，RSA 的这一对公钥、私钥都可以用来加密和解密，并且一方加密的内容可以由并且只能由对方进行解密。

加密：公钥加密，私钥解密的过程，称为「加密」。
因为公钥是公开的，任何公钥持有者都可以将想要发送给私钥持有者的信息进行加密后发送，而这个信息只有私钥持有者才能解密。

签名：私钥加密，公钥解密的过程，称为「签名」。

它和加密有什么区别呢？因为公钥是公开的，所以任何持有公钥的人都能解密私钥加密过的密文，所以这个过程并不能保证消息的安全性，但是它却能保证消息来源的准确性和不可否认性，也就是说，如果使用公钥能正常解密某一个密文，那么就能证明这段密文一定是由私钥持有者发布的，而不是其他第三方发布的，并且私钥持有者不能否认他曾经发布过该消息。故此将该过程称为「签名」。

数字证书

使用数字签名方法的前提，就是消息的接收者必须事先得到正确的公钥。如果一开始公钥就被别人篡改了，那坏人就会被你当成好人，而真正的消息发送者给你发的消息会被你视作无效的。如何保证公钥的安全可信呢？这就要靠数字证书来解决了。

数字证书是一个经证书授权（Certificate Authentication）中心数字签名的包含公钥拥有者信息以及公钥的文件。数字证书的格式普遍采用的是 X.509 V3 国际标准，一个标准的 X.509 数字证书通常包含以下内容：

证书的发布机构（Issuer）:由哪个机构（CA 中心）颁发。

证书的有效期（Validity）:证书的有效期，或者说使用期限。过了该日期，证书就失效了。

证书所有人的公钥（Public-Key）:证书所有人想要公布出去的公钥。

证书所有人的名称（Subject）:证书是发给谁的，或者说证书的所有者，一般是某个人或者某个公司名称、机构的名称、公司网站的网址等。

证书所使用的签名算法（Signature algorithm）:这个数字证书的数字签名所使用的加密算法，这样就可以使用证书发布机构的证书里面的公钥，根据这个算法对指纹进行解密。

证书发行者对证书的数字签名（Thumbprint）:该数字证书的指纹，用于保证数字证书的完整性，确保证书没有被修改过。

其原理就是在发布证书时，CA 机构会根据签名算法（Signature algorithm）对整个证书计算其 hash 值（指纹）并和证书放在一起，使用者打开证书时，自己也根据签名算法计算一下证书的 hash 值（指纹），如果和证书中记录的指纹对的上，就说明证书没有被修改过。
.
数字证书本身也用到了数字签名技术，只不过签名的内容是整个证书（里面包含了证书所有者的公钥以及其他一些内容）。与普通数字签名不同的是，数字证书的签名者不是随随便便一个普通机构，而是 CA 机构。
.
一般来说，这些 CA 机构的根证书已经在设备出厂前预先安装到了你的设备上了。所以，数字证书可以保证证书里的公钥确实是这个证书所有者的，或者证书可以用来确认对方的身份。可见，数字证书主要是用来解决公钥的安全发放问题。

一、什么是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（腾讯）都是非常优秀的方案。

V1

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

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

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 编码

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

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

V2

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

签名校验速度慢。校验过程中需要对apk中所有文件进行摘要计算，在 APK 资源很多、性能较差的机器上签名校验会花费较长时间，导致安装速度慢。
完整性保障不够。META-INF 目录用来存放签名，因此该目录本身是不计入签名校验过程的，可以随意在这个目录中添加文件，比如一些快速批量打包方案就选择在这个目录中添加渠道文件。

V3

四、apk签名校验

五、多渠道打包

https://tech.meituan.com/2017/01/13/android-apk-v2-signature-scheme.html

V1签名的多渠道原理：通过在META-INF目录下添加空文件，用空文件的名称来作为渠道的唯一标识，之前在META-INF下添加文件是不需要重新签名应用的，这样会节省不少打包的时间，从而提高打渠道包的速度。

V2签名的多渠道原理：在APK Signing Block区域增加ID-value扩展，增加自定义的渠道信息，保存到Apk中。

参考：
https://xuanxuanblingbling.github.io/ctf/android/2018/12/30/signature/
https://juejin.im/post/5cd239386fb9a0320f7dfcbe
https://www.jianshu.com/p/9ca1d6f3f083
Android 签名机制 v1、v2、v3