A. android | 他山之石，可以攻玉！一篇文章看懂 v1/v2/v3 签名机制
这篇文章的内容会涉及以下前置 / 相关知识，贴心的我都帮你准备好了，请享用~
数字签名（Digital Signature）也叫作数字指纹（Digital Fingerprint），它是消息摘要算法和非对称加密算法的结合体，能够验证数据的完整性，并且认证数据的来源 。
数据签名算法的模型分为两个主要阶段：
需要注意的是，Android 目前不对应用证书进行 CA 认证，应用可以由第三方（OEM、运营商、其他应用市场）签名，也可以自行签名。
应用 APK 其实是一种特殊的 Zip 压缩包，无法避免恶意破解者解压 / 反编译修改内容，针对这个问题有何解决方案呢？他山之石，可以攻玉 ——数字签名算法。应用签名正是数字签名算法的应用场景之一，与其他应用场景类似，目的无非是：
Android 平台上运行的每个应用都必须有开发者的签名。在慧唤安装应用时，软件包管理器会验证 APK 是否已经过适当签名，安装程序会拒绝没有获得签名就尝试安装的应用。
软件包管理器在安装应用前会验证应用摘要，如果破解者修改了 apk 里的内容，那么摘要就不再匹配，验证失败（验证流程见下文方案）。
截止至 Android 11，Android 支持以下三种应用签名方案：
为了提高兼容性，必须按照 v1、v2、v3 的先后顺序采用签名方案，低版本平台会忽略高版本的签名方案在 APK 中添加的额外数据。
v1 签名方案是基于 Jar 的签名。
首先，我们先来分析其签名产物。 v1 签名后会增加 META-INF 文件夹 ，其中会有如下三个文件。考虑到使用不同的证书和签名方式，得到的文件名可能不同，因此你只要留意文件的后缀即可：
v1 签名流程如下：
MANIFEST.MF（Message Digest File，摘要文件）
*.SF（Signature File，签名文件）
验证流程可以分为验证签名和验证完整性两个步骤：
验证签名步骤：
如果上述签名验证结果正确，才会验证完整性：
以上任何步骤验证失败，则整个 APK 验证失败。
为了解决这些问题，Android 7.0 中引入了 APK 签名方案 v2。
v2 签名方案是一种 全文件签名方案 ，该方案能够发现对 APK 的受保护部分进行的所有更改，相对于 v1 签名方案验证速度更快，完整性覆盖范围更广。
在分析 v2 签名方案之前，我们先简单了解一下 Zip 文件格式：
首先，我们先来分析其签名产物。v2 签名后会在 “条目内容区”和“中央目录区”之间插入“APK 签名分块（APK Signing Block）” 。
从左到右边，我们定义为区块 1~4。
相对与 v1 签名方案，v2 签名方案不再以文件为单位计算摘要了，而敬坦是以 1 MB 为单位将文件拆分为多个连续的块（chunk），每个分区的最后一个块可能会小于 1 MB。
v2 签亮碧桐名流程如下：
验证流程可以分为验证签名和验证完整性两个步骤：
签名方案 v3 支持密钥轮换，应用能够在 APK 更新过程中更改其签名密钥。
【累了，后面先不写了...】
这一节，我们介绍基于 Android 应用签名机制的衍生应用场景。
在 v1 方案中， MANIFEST.MF 和 *.SF 这两个文件会记录大量的文件名和文件摘要。如果 apk 中文件数很多，而且文件名很长，那么这两个文件会变得很大。使用 AndResGuard 工具，可以将文件名转换为短路径文件名，从而减少这两个文件的大小。
在实际生产中，往往需要生成多个渠道的 APK 包，传统的方法是使用 APKTool 逆向工具、Flavor + BuildType 等方案，这一类多渠道打包方案的缺点是耗时严重。随着 Android 应用签名方案的演进，演变出了不同的多渠道打包方案：
在 v1 方案中，我们提到了完整性校验不覆盖到 META-INF 文件夹的问题。有些多渠道打包方案就是利用了这个问题，在 META-INF 文件夹下添加空文件， 用空文件的名称来作为渠道的唯一标识 ，就可以节省打包的时间，提高打渠道包的速度。
除了添加空文件的方法，还可以向 APK 添加 Zip Comment 来生成多渠道包（APK 本身就是特殊的 Zip 包）。
在 v2 签名方案中，几乎整个 APK 都纳入保护范围，如果向 APK 添加空文件或 Zip Comment 的话，在安装时会报以下错误：
新背景下的多渠道打包方案，则是利用了 APK 签名分块（区块 2）不受保护 & 字段可扩展的特点 ，向区块中添加多渠道信息（ID-Value），例如 美团多渠道打包方案 Walle 。
B. 如何判断 Android 应用的 Apk 签名是否一致
一、判断Apk是否签名
用命令：jarsigner -verify -verbose -certs <apk文件>
1、如果有Android Debug字样就是debug
2、如果已经签名: [证书的有效期为13-8-31 下午2:31至41-1-16 下午2:31]
二、判断Apk签名是否一致
jdk 需要安装；想查demo.apk所使用的签名的fingerprint，可以这样做：
1、查找apk里的rsa文件
Windows 平台：
> jar tf demo .apk |findstr RSA
Linux 平台：
$ jar tf demo .apk |grep RSA
META-INF/CERT.RSA
2、 从apk中解压rsa文件
jar xf demo .apk META-INF/CERT.RSA
3、获取签名的fingerprints
keytool -printcert -file META-INF/CERT.RSA
证书指纹:
MD5: 5A:5A:96:63:8E:EF:FC:66:9E:BC:1C:2A:A9:1E:E5:95
SHA1: 44:BD:33:2D:C5:21:AE:78:D5:04:92:1A:39:FD:AC:01:E2:32:3C:AB
SHA256: 2F:C0:A3:8C:0D:42:84:70:48:78:44:A4:2E:64:5B:50:B3:B3:1E:33:94:62:A3:9F:2F:10:DD:EF:D7:CF:02:0B
签名算法名称: SHA1withRSA
版本: 3
两个apk是否同签名，比较签名的MD5码或SHA1码 ，一样就是相同的，反之，不是。
C. Android获取签名文件的sha1值
1.打开终端，输入：
keytool -v -list -keystore +签名文件路径
2.输入签名文件密码即可获取到签名文件所有信息：
创建日期: 2018-11-8 条目类型: PrivateKeyEntry 证书链长度: 1 证书[1]: 所有者: CN=fang 发布者: CN=fang 序列号: 4551a2f8 有效期开始日期: Thu Nov 08 11:17:27 CST 2018, 截止日期: Mon Nov 02 11:17:27 CST 2043 证书指纹: MD5: 2B:85:...... SHA1: 97:7D:...... SHA256: 1A:C5:F7:5C:...... 签名算法名称: SHA256withRSA 版本: 3
D. 一文弄懂关于证书，签名，ssl，android包签名机制。
所有的概念都基于一个非常重要的基础：
rsa 非对称加密算法 ：
先感受下几个概念
PKI。
PKI是公钥基础设施（Public Key Infrastructure) 包括PKI策略、软硬件系统、证书机构CA、注册机构RA、证书发布系统和PKI应用等。
我们关注就俩东西： PKCS 证书机构CA 。前者是定义加密算法，签名，证书相关的各种事情采用的协议。后者可以为我们颁发权威的证书。
PKCS ：
PKCS（The Public-Key Cryptography Standards ）是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。RSA算法可以做加密、解密、签名、验证，还有RSA的密钥对存储。这些都需要标准来规范，如何输入，如何输出，如何存储等。
PKCS。全称是公钥密码学标准， 目前共发布过 15 个标准，这些标准都是协议。总结一下 就是对加密算法，签名，证书协议的描述。下面列举一些常用的协议，这些协议在本文都会对应上。
这些协议具体的实现就体现在openssl等工具中， 以及jdk工具keytool jdk java第三方库bouncycastle。
比如用openssl 如何生成公/私钥(PKCS#1)、签名(PKCS#1 )、签名请求文件（KCS#10）、 带口令的私钥（PKCS#8）。 含私钥的证书（PKCS#12）、证书库（PKCS#12）
其中涉及到算法的基础协议PKCS#1等，由于涉及到密码学原理所以我们并不需要深究它，只要知道怎么做就可以了。
现实中我们要解决这样一种情况:
客户端和服务器之间的数据要进行加密。需要两个达成同一个对称秘钥加密才行，那么这个秘钥如何生成，并在两边都能拿到，并保证传输过程中不被泄露。 这就用到非对称加密了。 后续的传输，就能用这个 对称秘钥来加密和解密了。
还有这样一个问题：
就是客户端如何判断服务端是否是合法的服务端。这就需要服务端有个id来证明它，而这个id 就是证书，而且必须是权威机构颁发的才能算是合法的。
因为客户端即浏览器，认定证书合法的规则必须通过第三方来确认 即ca颁发的证书。否则就我可能进了一个假网站。
而这两个问题 都是ssl协议要解决的内容。
所以ssl协议做了两件事情，一是验证身份，二是协商对称秘钥，并安全的传输。 而实现这个过程的关键数据模型就是证书， 通过证书中的ca对证书的签名，实现了身份验证，通过证书中的公钥，实现对对称秘钥加密，从而实现数据保密。 其实还顺手做了一件事情就是通过解密签名比对hash，保证了数据完整性。
明白ssl协议 首先明白几个重要的概念：
证书： 顾名思义就是提供了一种在Internet上验证通信实体身份的方式，数字证书不是数字身份证，由权威公正的第三方机构，即CA（例如中国各地方的CA公司）中心签发的证书， 就是可以认定是合法身份的。客户端不需要证书。 证书是用来验证服务端的。
一般的证书都是x509格式证书，这是一种标准的证书，可以和其他证书类型互相转换。完整来说证书包含，证书的内容，包括 版本号， 证书序列号， hash算法， 发行者名称，有效期， 公钥算法，公钥，签名（证书原文以及原文hash一起签名）而这个内容以及格式 都是标准化的，即x509格式 是一种标准的格式。
签名: 就用私钥对一段数据进行加密，得到的密文。 这一段数据在证书的应用上就是 对证书原文+原文hash进行签名。
谁签的名，就是用谁的私钥进行加密。就像身份证一样， 合法的身份证我们都依据是政府签的，才不是假证， 那就是浏览器会有政府的公钥，通过校验（解密）签名，如果能够解密，就可以确定这个就是政府的签名。就对了。
hash算法 ：对原始数据进行某种形式的信息提取，被提取出的信息就被称作原始数据的消息摘要。比如，MD5和SHA-1及其大量的变体。 hash算法具有不可逆性，无法从摘要中恢复出任何的原始消息。长度总是固定的。MD5算法摘要的消息有128个比特位，SHA-1算法摘要的消息最终有160比特位的输出。
ca机构： 权威证书颁发机构，浏览器存有ca的公钥，浏览器以此公钥来验证服务端证书的合法性。
证书的获取： 生成证书申请文件.csr（涉及到PKCS#10定义的规范）后向ca机构申请。 或者自己直接通过生成私钥就可以一步到位生成自签名证书。 自签名证书就是用自己的私钥来签名证书。
那么为了体现到 证书身份认证、数据完整、保密性三大特性 ，证书的简化模型可以认为包含以下两个要素：服务器公钥，ca的签名（被ca私钥加密过的证书原文+原文hash），
身份认证：
浏览器存有ca公钥，用ca公钥解密网站发给你的证书中的签名。如果能解密，说明该证书由ca颁发，证书合法。 否则浏览器就会报警告，问你是否信任这个证书，也就是这个网站。这时候的证书可以是任何人签发的，可以自己签发的。 但是中间人攻击。 完全伪造新的证书， 这就没有办法了。 所以还是信任证书的时候要谨慎。
数据完整：
如果你信任该证书的话，这时候就会用证书中的公钥去解密签名，如果是ca签发的证书，那么之前就已经通过ca的公钥去解密签名了。 然后得到证书hash，然后在浏览器重新对证书做hash，两者比对一致的话，说明证书数据没有被篡改。
保密性：
使用证书的公钥对对称秘钥加密保证传输安全，对称秘钥生成后，后续的传输会通过对称秘钥来在服务端和客户端的加解密。
那么ssl协议的具体过程就是：
4.网站接收浏览器发来的数据之后 使用自己的私钥校验签名，并对原文进行hash 与解密出的hash 做比对检查完整性。然后发送编码改变通知，服务器握手结束通知（所有内容做hash ）。 发送给客户端校验。
5 客户端校验，校验成功后，之后就用 对称秘钥进行通信了。
总共的过程是 c-s-c- s-c 四次握手。
四次握手简单来说分别是：
1.请求获取证书
2.服务端返回证书，客户端验证了证书的合法性和完整性，同时生成了对称秘钥。
3.客户端把加密的 对称秘钥发给服务器。服务器检查真实性和完整性。
4.服务端返回握手结束通知，客户端再检查一次真实性和完整性。
前两次握手是明文， 后两次握手是密文。 所以都要检查身份真实性和数据完整性。
ca的作用：
ca起到一个权威中间人的角色，如果脱离了ca， 那么证书还是证书，还能加密，保证数据完整性。 但是无法应用在客户端去认定服务器身份合法这个场景下。
下面就详细说下 脱离了ca签发的证书的应用：
自签名证书：
证书如果没有权威机构的签名，就是没有权威机构给你签发身份证。 那么这时候身份认证的场景变了。
这时候的认证场景就变成了，不再是某个官方权威说了算，而是假设第一次碰到这个证书，会认为，这个证书与之捆绑的实体之间是合法的并做记录。如果当这个实体下次捆绑了另一个证书，那么就是非法的。
这种情况常用于android中安装和校验app的时候，会先假设第一次安装的是合法的应用，认定这个app证书中的公钥是合法的公钥。然后通过自签名的证书，校验签名，就能实现后续安装是否合法以及完整性。
android中的如何对app进行身份认定和不被篡改：
android系统在安装app时候会进行校验applicationId，applicationId 不同会认定为不同应用。相同应用，第二次安装会校验证书是否和之前app的证书相同，如果相同则两个包很可能来自同一个身份。 如果证书不同，也就是该包被另一个身份用自己的私钥重新签名过，就会拒绝安装。 然后通过公钥来解密签名，如果能解密，说明身份是ok的。否则拒绝安装。比对解密签名后的hash 与apk包内的cert.sf文件(该文件是apk内所有文件生成的hash文件)是否一致，如果相同则认定为没有被篡改。
android在提交应用商店的问题：
应用商店也会校验 后续的上传和第一次上传时的证书，以及类似上述的后续的一系列校验。防止合法的开发者平台被盗后，上传非法应用。
android在接入第三方sdk的问题：
接入第三方sdk 会提交applicationId 和 sha1 值。 这个sha1值就是对 证书原文的签名后的sha1，也就是证书指纹。这个证书是证书库里最初的那个证书（x509格式），而不是对apk签名后生成的证书(PKCS#7)。一般的证书签名的主体是证书原文本身，而对apk签名还额外会对apk所有文件生成的hash值文件（cert.sf）进行一次签名。
第三方平台会记录 applicationId 与sha1 的对应关系。 当有假冒app试图接入时候，由于会对app内的PKCS#7证书转换为原始的x509格式证书，重新生成sha1值，与用户提交sha1 比对， 如果相同则说明证书很可能是ok的。 因为sha1就是证书的指纹。 之后就会通过证书中的公钥来校验签名，从而最终确认身份合法性以及信息完整性。
第三方平台之所以需要用户去提交证书指纹sha1值，多了这一步，就意味着你的证书是可以更换的，一旦更换了证书，就必须提交新的指纹给我，然后我来做匹配。而应用商店没有这个功能， 一旦你的证书的私钥丢了， 那就必须重新建一个新的app。
总结来看证书的身份认定机制：
在ssl协议下，这种场景是 浏览器用于认定合法的服务器身份。 在自签名证书下，需要用户选择是否信任该证书。
在android app采用自签名证书的场景下， 证书起到了 假设第一次的证书合法，公钥合法，后续如果证书不一致或不能够完成签名校验，就是非法。
证书库：
证书库应该满足PKCS#12协议。 但是jdk提供了制作证书的工具keytool 可以生成keystore类型的证书库，后缀为jks。 keystore pk12可以通过keytool命令互相转换。
证书库是个证书的容器， 可以用来创建数字证书。 在keystore证书库中，所有的数字证书是以一条一条(采用别名alias区别)的形式存入证书库的。证书库中的证书格式为pk12，即包含私钥。 如果导出证书的话， 可以导出为x509不包含私钥的格式 或者pk12包含私钥的证书。 也可以也可以用-import参数加一个证书或证书链到信任证书。
android中一般都采用读取证书库的方式，通过证书库来创建一个证书，通过alias来区分。 所以在签名的时候，一个alias是一个证书，不同的alias是不同的证书，不要搞错了。
几个关系：
证书和非对称加密算法的关系：
证书代表一个身份的主体，包含了非对称秘钥体系中的公钥，以及用私钥对证书签名。这种组织结构，把非对称加密算法从加密的功能，拓宽到了用于身份认证，信息完整性上。这体现在了证书的作用。 本质还是利用了非对称加密算法的特性。
ssl协议和证书的关系。
因为证书解决了客户端对服务器的身份认证（自签名证书除外），同时也解决了加密，和信息完整性，所以ssl协议基于证书来实现。
E. 如何查看apk和签名文件的签名信息
1.通过apktool工具解压当前apk(比如：demo.apk)，解压后，会生成CERT.RSA文件
**** apktool d demo.apk
备注：通过这种方式解压出来的Androidmenifest.xml文件可以通过文件编辑器打开查看；
2.通过keytool命令获取签名信息
**** keytool -printcert -file C:\Android\soft\apktool\demo\original\META-INF\CERT.RSA所有者: CN=ryt, OU=ryt, O=ryt, L=nanjing, ST=china, C=cn
发布者: CN=ryt, OU=ryt, O=ryt, L=nanjing, ST=china, C=cn
序列号: 12893889
有效期开始日期:
证书指纹:
MD5: 1A:0F:52:94:8D:DB:7A:E9:7A:7E:A5:3B:A3:A7:F9:39
SHA1: 89:57:4E:E2:1F:CB:68:CB:66:80:D6:29:57:92:AD:AC:51:4F:76:F2
SHA256: BF:FB:9C:67:E1:7B:49:26:4A:D9:84:9D:48:DA:C1:4F:00:77:74:15:27:90:95:D0:B3:D8:0A:EA:2F:81:F1:B9
签名算法名称: SHA256withRSA
版本: 3
扩展:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: C3 D6 E3 9F C3 F3 1E BE 6E F9 BC 35 6F 8B 21 52 ........n..5o.!R
0010: 12 38 AD BC .8..
]
]
3.查看my.keystore签名文件的签名信息
**** keytool -list -keystore C:\Android\workspace\my.keystore
输入密钥库口令:
密钥库类型: JKS
密钥库提供方: SUN
您的密钥库包含 1 个条目
my, 2016-6-15, PrivateKeyEntry,
证书指纹 (SHA1): 89:57:4E:E2:1F:CB:68:CB:66:80:D6:29:57:92:AD:AC:51:4F:76:F2