AndroidV1,V2,V3签名原理详解

签名校验流程

基础知识：
1.数字签名
2.数字证书
3.对称加密和非对称加密

背景介绍：
一般开发者会指定使用自己创建的证书，如果没有指定，则会默认使用系统的证书，该默认的证书存储在C:\Users\admin.android\debug.keystore，不同的电脑可能安装不同路径。一个签名证书文件中，是包含一对公私钥，用私钥对apk进行签名，在安装到android手机时，系统会使用证书中对应签名私钥的公钥来验证，查看apk是否被更改过，如果没有则可以安装在手机上。任何的app store都不允许使用默认的debug.keystore打包的apk发布上去，因为debug.keystore的密码是默认的，不安全。
一，没有签名的APK无法安装
Android的APK要进行签名才能够安装到手机上，这是因为在安装的时候系统会进行检测，平时我们直接点AS里面那个绿色的运行按钮也能够直接安装到手机上，这是因为其实它也进行了签名，只不过AS自动帮我们做了这个操作有个默认的签名

（在.android目录中有个debug.keystore默认的签名）。

二，校验流程
9.0以上的系统会判断apk是否使用到V3版本的签名，如果有，那么按照V3版本签名校验方式进行校验校验成功直接安装，校验失败拒绝安装；如果apk不是使用V3签名，判断是不是使用V2,如果没有使用V2那么再判断是不是使用V1的签名。

三，进行V3签名
Android不支持V3版本的签名，所以在AS里面看不到V3。但是在SDK中有个签名工具apksigner.jar。只有9.0以上这个签名工具才能签V3版本的签名。

（如果想要签V3版本的签名，那么只能自己去使用这个签名工具在命令行中进行签名）

接下来详细介绍的就是不同的签名版本之间的区别。

不同的签名版本之间的区别

V1签名保护机制

保护APK中已有文件

基于JAR的签名。在打包后的apk中会多三个文件：

一.MANIFEST.MF

APK当中的所有文件都会列出来用Name表示，除此之外每个文件都有SHA-256签名摘要记录

签名摘要记录：校验码对我们的数据内容进行验证，防止别人会修改你的文件。如果文件改动那么对应的检验码就会不一致

二.CERT.SF
这里面存放的和上面MANIFEST.MF的内容一样，只不过多了一个文件就是MANIFEST.MF文件，并对它进行了和其他文件一样的操作：生成校验码。

目的：上面说过修改了文件后，如果只是和之前文件的校验码对比是可以检测到修改的。但是如果我把文件和校验码都进行修改，那么他就检测不出来，这样的安全性就太低了。所以我们把上面的MANIFEST.MF文件也给他进行一次校验。

但是如果你把SF文件和校验码也改了呢？接下来看最后一个文件CERT.RSA

三.CERT.RSA
在签名的时候会给一个证书，里面有公钥和私钥；
这个RSA文件使用私钥计算SF文件的数字签名+包含公钥的证书信息保存到RSA文件中。

第三层防护：理论上没有私钥是无法伪装数字签名的。

总结：
RSA文件保护SF文件，SF文件保护MF文件，MF文件保护apk中已有的所有文件

注意：V1签名保护的是APK中已有文件不被修改，但是新加的文件并不会受影响。

下面我们来分析一下，如果apk文件被篡改后会发生什么。

首先，如果你改变了apk包中的任何文件，那么在apk安装校验时，改变后的文件摘要信息与MANIFEST.MF的检验信息不同，于是验证失败，程序就不能成功安装。

其次，如果你对更改的过的文件相应的算出新的摘要值，然后更改MANIFEST.MF文件里面对应的属性值，那么必定与CERT.SF文件中算出的摘要值不一样，照样验证失败。

最后，如果你还不死心，继续计算MANIFEST.MF的摘要值，相应的更改CERT.SF里面的值，那么数字签名值必定与CERT.RSA文件中记录的不一样，还是失败。
那么能不能继续伪造数字签名呢？不可能，因为没有数字证书对应的私钥。

所以，如果要重新打包后的应用程序能再Android设备上安装，必须对其进行重签名。
从上面的分析可以得出，只要修改了Apk中的任何内容，就必须重新签名，不然会提示安装失败。

V2签名保护机制

保护的是整个APK的字节数据

原理：apk文件本身就是一个zip文件，按照ZIP文件格式插入APK Signing Block分块去记录签名信息

APK Signing Block格式：

size of block: APK分块总长度-8
id-value paris: id与value数据总长度
id:id数据
value:value数据
size of block:与第一个字段相同
magic:魔数（标记文件格式，目的为了快速识别文件格式）

举例：
假如APK签名分块数据总长度为108

size of block：100（108-8）
id-value paris：X（id和value总长度）
id：(4个字节)
value：签名信息（X-4）
size of block：100（108-8）
magic:ZIP文件的魔数

其中可以有多个id-value paris,id和value

那么前面说过V2签名保护的是整个ZIP文件的字节数据，那么具体是保护哪些呢：

可以看到保护的是1,3，4部分和刚才图里面的APK中V2签名存储的其中一个ID值对，但是"刚刚说了可以有多个id-value paris,id和value值对，所以我们可以添加这些东西而且不会影响签名机制"

V3签名保护机制

V3签名和V2签名类似，区别：
一，V3签名多了一个判断机制：“APK签名数据块大小必须是4096的倍数”
二，V3签名分块采用V2相同的签名分块格式，只不过改了V2签名分块中的那个ID
三，增添了有关受支持的SDK版本和prof-of-rotation结构的信息

怎样判断使用的是哪种签名

V1直接看APK的目录就可以分辨
另外两个涉及到了EOCD格式中有一个值代表Central Directory到Contents of Zip Entries的位移，
这里就用图去表示了。。

由此也可以得出：偏移量-APK签名分块长度=签名分块从第几个字节开始
偏移量：上面提到过在EOCD格式中存储着
APK签名分块长度：偏移量-16个字节（magic魔数）-8个字节（size of block）

参考链接：

https://www.2cto.com/kf/201512/455388.html