一文看懂Android签名v1v2v3v4，竟然都v4了？

　　本文作者：九心，原文发布于：九心说。
　　前言
　　最近帮测试做了一点关于签名的需求，今天就和各位同学简单聊一聊关于签名的那些事儿。
　　如果问到Android为什么需要签名？大家都可能想到官网的解释：
　　Android系统要求所有APK必须先使用证书进行数字签名，然后才能安装到设备上进行更新。
　　这是一个比较模糊的解释，简单来说，有了签名，就可以让App和开发者绑定。
　　毕竟，应用那么多，别的开发者也有可能盗用你的代码，这个时候，包名和你相同，代码和你相同，怎么区分你的App和这些人的App不是同一个呢？
　　这个时候数字签名就派上用场了。
　　1hr签名基础
　　想要彻底了解签名知识，我们得了解以下知识：消息摘要数字签名加密数字证书
　　这一系列的知识各位可能在学习网络的时候或多或少的接触过。
　　我们简单的学习一下这些知识：1。消息摘要
　　消息摘要常常被被称为数字摘要或者数字指纹，定义如下：
　　在原来的数据基础上，经过一个单向的Hash计算，得到一个固定的Hash值，这就是消息摘要。
　　常见的摘要算法都有MD5、SHA1和SHA256，特点如下：
　　1。长度固定，与内容长度无关：比如MD5是128位、SHA1是160位、SHA256是256位。
　　2。看似随机，其实不随机：同内容两次摘要得出的结果一致。
　　3。单向：只能从原数据得出摘要，不能从消息摘要得出原来的数据。
　　4。优秀的摘要算法很难Hash碰撞。
　　基于此，消息摘要常常会被用来检查内容的完整性。
　　比如我们下载起点读书，消息摘要的用法如下：
　　1。计算摘要：App会针对自己的文件信息计算出一个数字摘要比如123。。。123。
　　2。下载App。
　　3。验证摘要：对下载的App再次计算摘要，比如得出的也是123。。。123，和之前的数字摘要一对比，这就代表我从服务器下载的内容是完整的，可以正常使用。
　　当然，上面只涉及了摘要部分，其他过程，我们后面分析。2。加密算法
　　什么是加密？
　　百科是这么解释的：
　　将明文信息改变为难以读取的密文内容，使之不可读的过程。只有拥有解密方法的对象，经由解密过程，才能将密文还原为正常可读的内容。
　　所以啊，加密方法得到的密文是可以转变为明文的，像信息摘要算法比如MD5得出来的结果是不可逆的，所以面试官问你们什么是加密算法的时候，你可不能把MD5说进去！
　　加密算法分为两大类，对称加密和非对称加密。2。1对称加密
　　对称加密在加密和解密的时候使用的同一把钥匙：
　　图片来自《一文彻底搞懂加密、数字签名和数字证书！》2。2非对称加密
　　非对称加密是使用公钥私钥中的公钥来加密明文，然后使用对应的私钥来解密密文的过程：
　　图片来自《一文彻底搞懂加密、数字签名和数字证书！》
　　简单对比一下对称加密和非对称机密：
　　非对称加密
　　对称加密
　　速度
　　慢
　　快
　　效率
　　低
　　高
　　安全性
　　高
　　低
　　常见算法
　　RSADH
　　AESDESIDEA2。3使用场景
　　学过网络的同学应该都了解，在Https的传输过程中，客户端和服务端使用非对称加密生成对称加密的密钥，然后用对称加密传输网络中的数据。
　　比如我上大学那会儿，每个月的月尾我和我妈的对话是这样的：
　　对话
　　网络环境是开放的，万一这时，有一个黑客监听了我和我妈的对话，过程就变成了这样：
　　监听过程
　　在我发卡号的时候，黑客将我的卡号改成了他的卡号，于是我的生活费变成了他的生活费。
　　为了避免这种情况，于是我和我妈约定好了，每次发送前，使用对称加密对消息进行加密，接受消息的时候使用密钥解密，过程就变成了这样：
　　对称加密
　　中间人再也不能获取到消息了，看似一点问题都没有，但是我和老妈之间如何确定密钥呢？
　　密钥总要在互联网之间进行传输的，有传输就有被中间人截获的风险，一旦被截获，钱可就没了！
　　为了解决对称加密钥匙传输的问题，我和老妈用上了非对称加密，像这样：
　　非对称加密
　　即使这样，还是有问题存在：
　　1。怎么才能确认我获得的公钥来自老妈？
　　2。如何确定消息确实来自老妈？
　　解决这两个问题也很简单，一是数字签名，二就是数字证书。3。数字签名
　　数字签名的作用是为了消息的完整性。
　　在非对称加密的体系下，消息的发送过程是这样的，还是上面的例子：
　　数字签名
　　数字签名的过程是这样的：
　　1。我发送消息前，利用Hash算法针对数据得出一个摘要。
　　2。我使用老妈的公钥对摘要内容进行加密，连同对称加密的数据一起发送过去。
　　3。老妈接收到消息后，先利用对称密钥对内容解密，再进行Hash计算得出摘要。
　　4。老妈使用私钥将摘要内容解密，和再次计算得出的摘要作对比，一致就代表消息无误。
　　上面的这种场景其实有点不妥，数字签名一般用在证书上，协商好对称密钥以后一般不会进行消息完整性校验了，不过大伙只要了解数字签名要来校验消息完整性就好。
　　截止现在，还有最后一个问题，我无法确认获取的公钥确实来自老妈。4。数字证书
　　证书的作用很简单，证明公钥的身份。
　　就像在现实中，大家都是怎么证明自己的身份的？
　　没错，是身份证。你有没有发现，每张身份证，会有三种信息：
　　1。自身的信息。
　　2。置办身份证的派出所。
　　3。有效期。
　　对应的数字证书也有很多内容：
　　1。CA：证书的颁发机构。
　　2。证书的有效期。
　　3。公钥。
　　4。证书的授予对象。
　　CA将这些内容利用CA的私钥进行签名，用户使用CA的公钥验签，从而证明公钥的身份。
　　常见的证书分为两种：
　　1。签名证书：由CA机构颁发，绝大部分网站都采用的这种方式。
　　2。自签名证书：由服务器自己颁发给自己。
　　重回之前的例子，老妈只需要将自己的签名证书发给我，我就可以获取她的公钥，之后就可以正常的通信。
　　2hrAndroid签名机制
　　在Android中，也需要使用数字证书做数字签名，数字证书中公钥对应的私钥由开发者持有。
　　关于私钥和证书的生成方式，可以查看：
　　《Android官方文档》
　　https：developer。android。comstudiopublishappsigning？hlzhcndebugmode
　　在AndroidStudio中，最终会生成一个。jks的文件，早期Eclipse是。keystore，它们都是用作证书和私钥的二进制文件。
　　App如果使用了一种私钥签名，另外一个私钥签名的文件将无法安装或覆盖老的版本，这样做是为了防止已经安装的App被恶意的第三方覆盖。1。Android签名机制的异同点
　　Android中数字签名的生成和普通的数字签名并没有很大的区别。
　　但是进行数字签名的证书可以采用自签名证书，即不需要权威证书颁发机构（CA）来做背书，因为它的作用是用来标识应用程序的开发者，下载的用户并不需要这个证书来下载该App。2。Debug和Relase的签名
　　当我们在IDE中运行或调试项目时，AS会自动使用AndroidSDK工具生成的调试证书为我们的应用签名，路径为HOME。androiddebug。keystore，但是应用商店可不接受使用调试证书发布的应用签名。
　　打包Release时，我们一般会在app模块中的build。gradle进行配置：android｛。。。signingConfigs｛release｛storeFilefile（release。keystore）storePasswordkeyAliaskeyPassword｝｝｝
　　这些都是我们生成。jks或者。keystore需要生成的参数。
　　3hr签名方案
　　目前Android支持以下四种应用签名方案：
　　1。v1方案：基于JAR签名。
　　2。v2方案：Android7。0引入，改动大。
　　3。v3方案：Android9。0引入，基于v2的升级。
　　4。v4方案：Android11。0引入，用来支持ADB增量APK安装。1。v1方案
　　v1是一个老生常谈的签名了，签名过程也很简单。
　　我们如果选中一个任意签名后的apk进行解压，会找到一个METAINF文件，这个文件里一般会有以MF、SF和RSA结尾的文件，如图：
　　这些文件在v1签名流程中是这样的：
　　v1流程
　　验证过程在Apk安装的过程中：
　　v1验证
　　整个过程清晰明了，但v1有两个问题：
　　第一个问题是签名校验慢，要针对Apk中所有的文件进行校验，这会拖累老设备的安装时间。
　　第二个问题是仅针对ZIP条目校验，METAINF文件不会计入校验过程。这样会导致即使我Apk已经签过名，工程师也可以移动条目顺序并重新压缩，也可以修改METAINF文件下的内容，带来一些安全隐患，早期的多渠道打包就是在这里做的文章。2。v2方案
　　v2是Android签名方案的一大步，它解决了v1遗留的签名校验慢和完整性的问题。
　　我们先来看一下v2的组成部分：
　　签名前和签名后的APK
　　v1的组成部分其实就和Beforesigning那一块儿一样，v2多了红色区域，我们称之为APK签名分块。
　　签名后的各个APK部分
　　从保护的内容来看，v1仅保护内容1，v2保护的区域有1、3、4和2的signeddata区域，signeddata是1、3和4得出来的摘要等信息。签名过程
　　就一个App而言，它可能有一个或者多个签名者，对于每个签名者而言，都会进行签名过程。
　　v2没有对每个文件都进行计算，而是针对的所有字节。它将1、3和4区域都拆分成了大小为1MB的连续块，计算方式如下：
　　1。每个小块都按：字节0xa5块字节长度块内容进行计算。
　　2。每个1、3和4块都按：字节0xa5块数小块摘要进行计算。
　　最后，将这些一个或者多个签名者的摘要、证书等信息都打包到Apk中。
　　v2流程验签过程
　　v2方案的APK验证过程是这样的：
　　1。找到APK签名分块区域。
　　2。每找到一个签名者，都会验证：签名算法、信息摘要、证书和公钥。
　　3。所有的签名者都验证通过了，APK验证才会通过。3。v3方案
　　v3方案建立在v2的基础上，目标是解决在更新过程中更改签名密钥的问题。
　　所以APK签名分块中添加了两部分内容：
　　1。Proofofrotation：一个存在替换的所有旧签名证书的链表，根节点是最旧的证书。
　　2。SDK版本支持。
　　v3和v2的签名过程和验证过程几乎一致，就不写出来了。4。v4方案
　　如果同学们经常玩一些主机游戏，可以发现，在PS5或者Swtich上，一些游戏即使没有安装完成，我们也可以打开游戏玩一些基本功能，比如我以前常玩的NBA2k系列。
　　Android11中谷歌也新增了ADB增量APK安装功能，比如一个APK有2GB，我下载完50MB以后，就可以使用一些基本功能，剩余的文件通过后台流式传输，不过Android11中的这个功能是面向ADB的。
　　虽然这个功能很赞，但是对签名方案带来了一些挑战，之前的方案都是基于所有文件进行校验的，于是推出Android第四代签名方案v4。
　　v4基于APK所有的字节计算出MerkleHash树，并将Merkle树的根Hash、盐值作为签名数据进行包完整性校验，v4签名必须单独存在。idsig文件中，不会存在于APK文件中，所以apk文件中仍然需要v2或者v3签名。5。向下兼容的签名方案
　　Android中的签名方案是自上而下兼容的，如图：
　　APK验证流程v4
　　对于Android11来说，验证过程是这样的：
　　1。是否支持v4，v4验证完了再验证v3或者v2
　　2。v4不通过，验证v3
　　3。v3不通过，验证v2
　　4。v2不通过，验证v1
　　5。v1不通过，安装失败
　　对于Android9来说，就得从v3方案开始验证的。总结
　　读完这篇文章，相信你对Android签名方案有了基础的了解。
　　如果文章有不对的地方，评论区见
　　参考文章：
　　Android签名机制v1、v2、v3
　　《增量安装与安卓V4签名简介》
　　http：cnsec。comarchives224626。html
　　《官方文档》
　　https：source。android。google。cnsecurityapksigning？hlzhcn
　　作者：九心
　　来源：微信公众号：鸿洋
　　出处：https：mp。weixin。qq。coms？bizMzAxMTI4MTkwNQmid2650844929idx1sn8d58e1214f4967c2a70f2b47620a5017