参考资料Android签名机制之—签名过程详解
HTTPS演化过程
android的签名，说来惭愧；接触android这么长时间了，对其原理如果口述的话还不能说出个一二三来，所以用此篇博文做一个学习笔记。
我们知道非对称加密中可以有两种：一种就是公钥加密，私钥解密。另外一种就是私钥加密，公钥解密。其中前者主要用于通信，后者主要用户验证签名。而后者即私钥加密，公钥解密其实就是android签名的主要理论依据。
先来一个简单的流程图来说明一下验签的过程(图1)：
逻辑也很简单，就是在客户端持有服务端公钥的情况下，服务度端将要发送的源数据先生成摘要，然手对摘要用私钥进行加密生成数字签名。将源数据和数字签名一并发给客户端，客户端接收到这两个数据后，用与服务端同样的摘要算法提取源数据的摘要信息A；客户端再用公钥解密了数字签名获取服务端生成的数字签名B；如果A和B这两个签名一致，则证明数据未被篡改。
那么在android中是怎么体现呢？用解压缩软件解压apk或者直接用as打开apk文件，博主解压后的apk文件目录如下图2：
我们可以在META-INF文件夹下看到下面三个文件：MANIFEST.MF,CERT.SF，CERT.RSA
打开MAINFEST.MF这个文件可以发现，其实该文件的内容就是图2中的每个文件（非文件夹）用SHA1（或其他）消息摘要算法提取文件的摘要信息，然后将摘要通过BASE64之后作为SHA1-Digest属性的值写入到MANIFEST.MF中，见图3：。
也就是说通过MANIFEST.MF我们可以拿到apk目录文件下每个文件的摘要信息。
所以如果在下载apk的过程中，apk中的任意一个文件被篡改，那么更改后的摘要文件跟MANIFEST.MF肯定不匹配此时就会安装失败。那这很好破解啊！我篡改apk文件的同时，生成新的摘要；然后修改MANIFEST.MF对应SHA1-Digest属性里的摘要值不就可以了？别慌，我们还有CERT.SF文件。该文件主要做了两件事：
1、通过SHA1摘要算法计算出MANIFEST.MF文件的数据摘要，经过base64之后作为CERT.SF文件中SHA1-Digest-Manifest属性的值存储下来
2、遍历MANIFEST.MF的每一块的摘要，base64之后，记录在CERT.SF中的同名块中，属性的名字是“SHA1-Digest
所以CERT.SF的文件结构跟MANIFEST.MF看起来差不多，见图4：
所以有了CERT.SF这个文件之后，即使我们对MANIFEST.MF文件做了修改，那么就会导致MANIFEST.MF摘要信息和CERT.SF不匹配，也会导致无法安装！但是问题又来了，如果我即修改apk目录下的文件，有修改了对应了MANIFEST.MF，同时也对应的修改了CERT.SF里面的值，那么这个岂不是有破解了？别慌CERT.RSA此时来救场了！！！
发现没有，通过图1的流程，我们需要对摘要用私钥进行加密,保证源数据不被篡改。但是MANIFEST.MF和CERT.SF都没有进行私钥加密操作，这就让我们有修改MANIFEST.MF和CERT.SF的可能性！所以不言而喻CERT.RSA的作用就是对CERT.SF的摘要用私钥进行加密生成签名！！！然后将签名以及包含公钥信息的数字证书一同写入 CERT.RSA 中保存。
所以即使同时修改了apk,MAINFEST.MF,CERT.SF，那么数字签名必定和 CERT.RSA不一样，所以就可以判断出apk已经不是那个apk了。只要我们保护安好自己的私钥，那么apk就不会被篡改。
所以只要修改了apk的任何内容，就必须重新签名，否则会安装失败。
