Android签名机制
什么是Android签名
了解 HTTPS 通信的同学都知道,在消息通信时,必须至少解决两个问题:一是确保消息来源的真实性,二是确保消息不会被第三方篡改。
同理,在安装 apk 时,同样也需要确保 apk 来源的真实性,以及 apk 没有被第三方篡改。为了解决这一问题,Android官方要求开发者对 apk 进行签名,而签名就是对apk进行加密的过程。要了解如何实现签名,需要了解两个基本概念:消息摘要、数字签名和数字证书。
消息摘要
消息摘要(Message Digest),又称数字摘要(Digital Digest)或数字指纹(Finger Print)。简单来说,消息摘要就是在消息数据上,执行一个单向的 Hash 函数,生成一个固定长度的Hash值,这个Hash值即是消息摘要。
上面提到的的加密 Hash 函数就是消息摘要算法。它有以下特征:
无论输入的消息有多长,计算出来的消息摘要的长度总是固定的。
例如:应用 MD5 算法摘要的消息有128个比特位,用 SHA-1 算法摘要的消息最终有 160 比特位的输出,SHA-1 的变体可以产生 192 比特位和 256 比特位的消息摘要。一般认为,摘要的最终输出越长,该摘要算法就越安全。
消息摘要看起来是「随机的」。
这些比特看上去是胡乱的杂凑在一起的。可以用大量的输入来检验其输出是否相同,一般,不同的输入会有不同的输出,而且输出的摘要消息可以通过随机性检验。但是,一个摘要并不是真正随机的,因为用相同的算法对相同的消息求两次摘要,其结果必然相同;而若是真正随机的,则无论如何都是无法重现的。因此消息摘要是「伪随机的」。
消息摘要函数是单向函数,即只能进行正向的信息摘要,而无法从摘要中恢复出任何的消息,甚至根本就找不到任何与原信息相关的信息。
当然,可以采用强力攻击的方法,即尝试每一个可能的信息,计算其摘要,看看是否与已有的摘要相同,如果这样做,最终肯定会恢复出摘要的消息。但实际上,要得到的信息可能是无穷个消息之一,所以这种强力攻击几乎是无效的。
好的摘要算法,没有人能从中找到「碰撞」。或者说,无法找到两条消息,使它们的摘要相同。
虽然「碰撞」是肯定存在的(由于长明文生成短摘要的 Hash 必然会产生碰撞)。即对于给定的一个摘要,不可能找到一条信息使其摘要正好是给定的。
正是由于以上特点,消息摘要算法被广泛应用在「数字签名」领域,作为对明文的摘要算法。著名的消息摘要算法有 RSA 公司的 MD5 算法和 SHA-1 算法及其大量的变体。SHA-256 是 SHA-1 的升级版,现在 Android 签名使用的默认算法都已经升级到 SHA-256 了。
正是因为消息摘要具有这种特性,很适合来验证数据的完整性。比如:在网络传输过程中下载一个大文件 BigFile,我们会同时从网络下载 BigFile 和 BigFile.md5,BigFile.md5 保存 BigFile 的摘要,我们在本地生成 BigFile 的消息摘要和 BigFile.md5 比较,如果内容相同,则表示下载过程正确。
数字签名
数字签名的作用就是保证信息传输的完整性、发送者的身份认证、防止交易中的抵赖发生。数字签名技术是将摘要信息用发送者的私钥加密,与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息然后用HASH函数对收到的原文产生一个摘要信息,与解密的摘要信息对比。如果相同,则说明收到的信息是完整的,在传输过程中没有被修改,否则说明信息被修改过,因此数字签名能够验证信息的完整性。
如 RSA 作为数字签名方案使用时,它的使用流程如下:这种签名实际上就是用信源的私钥加密消息,加密后的消息即成了签体;而用对应的公钥进行验证,若公钥解密后的消息与原来的消息相同,则消息是完整的,否则消息不完整。
RSA正好和公钥密码用于消息保密是相反的过程。因为只有信源才拥有自己地私钥,别人无法重新加密源消息,所以即使有人截获且更改了源消息,也无法重新生成签体,因为只有用信源的私钥才能形成正确地签体。
同样信宿只要验证用信源的公钥解密的消息是否与明文消息相同,就可以知道消息是否被更改过,而且可以认证消息是否是确实来自意定的信源,还可以使信源不能否认曾经发送的消息。所以 这样可以完成数字签名的功能。
但这种方案过于单纯,它仅可以保证消息的完整性,而无法确保消息的保密性。而且这种方案要对所有的消息进行加密操作,这在消息的长度比较大时,效率是非常低的,主要原因在于公钥体制的加解密过程的低效性。所以这种方案一般不可取。
几乎所有的数字签名方案都要和快速高效的摘要算法(Hash 函数)一起使用,当公钥算法与摘要算法结合起来使用时,便构成了一种有效地数字签名方案。
签名证书
通过数字签名技术,确实可以解决可靠通信的问题。一旦验签通过,接收者就能确信该消息是期望的发送者发送的,而发送者也不能否认曾经发送过该消息。
大家有没有注意到,前面讲的数字签名方法,有一个前提,就是消息的接收者必须事先得到正确的公钥。如果一开始公钥就被别人篡改了,那坏人就会被你当成好人,而真正的消息发送者给你发的消息会被你视作无效的。而且,很多时候根本就不具备事先沟通公钥的信息通道。
那么如何保证公钥的安全可信呢?这就要靠数字证书来解决了。
数字证书是一个经证书授权(Certificate Authentication)中心数字签名的包含公钥拥有者信息以及公钥的文件。数字证书的格式普遍采用的是 X.509 V3 国际标准,一个标准的 X.509 数字证书通常包含以下内容:
证书的发布机构(Issuer):该证书是由哪个机构(CA 中心)颁发的。
证书的有效期(Validity):证书的有效期,或者说使用期限。过了该日期,证书就失效了。
证书所有人的公钥(Public-Key):该证书所有人想要公布出去的公钥。
证书所有人的名称(Subject):这个证书是发给谁的,或者说证书的所有者,一般是某个人或者某个公司名称、机构的名称、公司网站的网址等。
证书所使用的签名算法(Signature algorithm):这个数字证书的数字签名所使用的加密算法,这样就可以使用证书发布机构的证书里面的公钥,根据这个算法对指纹进行解密。
证书发行者对证书的数字签名(Thumbprint):数字证书的hash 值(指纹),用于保证数字证书的完整性,确保证书没有被修改过。
数字证书的原理就是在证书发布时,CA 机构会根据签名算法(Signature algorithm)对整个证书计算其 hash 值(指纹)并和证书放在一起,使用者打开证书时,自己也根据签名算法计算一下证书的 hash 值(指纹),如果和证书中记录的指纹对的上,就说明证书没有被修改过。
可以看出,数字证书本身也用到了数字签名技术,只不过签名的内容是整个证书(里面包含了证书所有者的公钥以及其他一些内容)。与普通数字签名不同的是,数字证书的签名者不是随随便便一个普通机构,而是 CA 机构。
总结一下,数字签名和签名验证的大体流程如下图所示:
Android打包流程
整个Android的打包流程如下图所示:
编译打包步骤:
1,打包资源文件,生成R.java文件
打包资源的工具是aapt(The Android Asset Packaing Tool)(E:\Documents\Android\sdk\build-tools\25.0.0\aapt.exe)。
在这个过程中,项目中的AndroidManifest.xml文件和布局文件XML都会编译,然后生成相应的R.java,另外AndroidManifest.xml会被aapt编译成二进制。
存放在APP的res目录下的资源,该类资源在APP打包前大多会被编译,变成二进制文件,并会为每个该类文件赋予一个resource id。对于该类资源的访问,应用层代码则是通过resource id进行访问的。Android应用在编译过程中aapt工具会对资源文件进行编译,并生成一个resource.arsc文件,resource.arsc文件相当于一个文件索引表,记录了很多跟资源相关的信息。
2. 处理aidl文件,生成相应的Java文件
这一过程中使用到的工具是aidl(Android Interface Definition Language),即Android接口描述语言(E:\Documents\Android\sdk\build-tools\25.0.0\aidl.exe)。
aidl工具解析接口定义文件然后生成相应的Java代码接口供程序调用。如果在项目没有使用到aidl文件,则可以跳过这一步。
3. 编译项目源代码,生成class文件
项目中所有的Java代码,包括R.java和.aidl文件,都会变Java编译器(javac)编译成.class文件,生成的class文件位于工程中的bin/classes目录下。
4. 转换所有的class文件,生成classes.dex文件
dx工具生成可供Android系统Dalvik虚拟机执行的classes.dex文件,该工具位于(E:\Documents\Android\sdk\build-tools\25.0.0\dx.bat)。
任何第三方的libraries和.class文件都会被转换成.dex文件。dx工具的主要工作是将Java字节码转成成Dalvik字节码、压缩常量池、消除冗余信息等。
5. 打包生成APK文件
所有没有编译的资源,如images、assets目录下资源(该类文件是一些原始文件,APP打包时并不会对其进行编译,而是直接打包到APP中,对于这一类资源文件的访问,应用层代码需要通过文件名对其进行访问);编译过的资源和.dex文件都会被apkbuilder工具打包到最终的.apk文件中。
打包的工具apkbuilder位于 android-sdk/tools目录下。apkbuilder为一个脚本文件,实际调用的是(E:\Documents\Android\sdk\tools\lib)文件中的com.android.sdklib.build.ApkbuilderMain类。
6. 对APK文件进行签名
一旦APK文件生成,它必须被签名才能被安装在设备上。
在开发过程中,主要用到的就是两种签名的keystore。一种是用于调试的debug.keystore,它主要用于调试,在Eclipse或者Android Studio中直接run以后跑在手机上的就是使用的debug.keystore。
另一种就是用于发布正式版本的keystore。
7. 对签名后的APK文件进行对齐处理
如果你发布的apk是正式版的话,就必须对APK进行对齐处理,用到的工具是zipalign(E:\Documents\Android\sdk\build-tools\25.0.0\zipalign.exe)
对齐的主要过程是将APK包中所有的资源文件距离文件起始偏移为4字节整数倍,这样通过内存映射访问apk文件时的速度会更快。对齐的作用就是减少运行时内存的使用。
从上图可以看到,签名发生在打包过程中的倒数第二步,而且签名针对的是已经存在的apk包,并不会影响我们写的代码。事实也确实是如此,Android的签名,大致的签名原理就是对未签名的apk里面的所有文件计算hash,然后保存起来(MANIFEST.MF),然后在对这些hash计算hash保存起来(CERT.SF),然后在计算hash,然后再通过我们上面生成的keystore里面的私钥进行加密并保存(CERT.RSA)。
Android签名方案
Android 系统从诞生到现在的1.0版本,一共经历了三代应用签名方案,分别是v1、v2和v3方案。
- v1 方案:基于 JAR 签名。
- v2 方案:APK 签名方案 v2,在 Android 7.0 引入。
- v3 方案:APK 签名方案v3,在 Android 9.0 引入。
其中,v1 到 v2 是颠覆性的,主要是为了解决 JAR 签名方案的安全性问题,而到了 v3 方案,其实结构上并没有太大的调整,可以理解为 v2 签名方案的升级版。
v1 到 v2 方案的升级,对开发者影响是最大的,就是渠道签署的问题。v2的签名也是为了让不同渠道、市场的安装包有所区别,携带渠道的唯一标识,也即是我们俗称的渠道包。好在各大厂都开源了自己的签渠道方案,例如:Walle(美团)、VasDolly(腾讯)都是非常优秀的方案。
签名工具
Android 应用的签名工具有两种:jarsigner 和 apksigner。它们的签名算法没什么区别,主要是签名使用的文件不同。它们的区别如下:
jarsigner:jdk 自带的签名工具,可以对 jar 进行签名。使用 keystore 文件进行签名。生成的签名文件默认使用 keystore 的别名命名。
apksigner:Android sdk 提供的专门用于 Android 应用的签名工具。使用 pk8、x509.pem 文件进行签名。其中 pk8 是私钥文件,x509.pem 是含有公钥的文件。生成的签名文件统一使用“CERT”命名。
既然这两个工具都是给 APK 签名的,那么 keystore 文件和 pk8,x509.pem 他们之间是不是有什么联系呢?答案是肯定的,他们之间是可以转化的,这里就不再分析它们是如何进行转化,网上的例子很多。
还有一个需要注意的知识点,如果我们查看一个keystore 文件的内容,会发现里面包含有一个 MD5 和 SHA1 摘要,这个就是 keystore 文件中私钥的数据摘要,这个信息也是我们在申请很多开发平台账号时需要填入的信息。
签名过程
首先,我们任意选取一个签名后的 APK(Sample-release.APK)进行解压,会得到如下图所示的文件。
可以发现,在 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 认证。
这里看到的都是二进制文件,因为 使用RSA 加密了,所以我们需要用 openssl 命令才能查看其内容,如下所示。
$ openssl pkcs7 -inform DER -in /<文件存放路径>/Sample-release_new/original/Meta-INF/CERT.RSA -text -noout -print_certs
执行上面的命令后,得到的内容如下图:
综上可以看出,一个完整的签名过程如下图:
签名校验
签名验证是发生在 APK 的安装过程中,一共分为三步:
- 检查 APK 中包含的所有文件,对应的摘要值与 MANIFEST.MF 文件中记录的值一致。
- 使用证书文件(RSA 文件)检验签名文件(SF 文件)没有被修改过。
- 使用签名文件(SF 文件)检验 MF 文件没有被修改过。
综上所述,一个完整的签名验证过程如下所示:
APK 签名方案 v2 是一种全文件签名方案,该方案能够发现对 APK 的受保护部分进行的所有更改,从而有助于加快验证速度并增强完整性保证。通过前面的分析,可以发现 v1 签名有两个地方可以改进:
签名校验速度慢
校验过程中需要对apk中所有文件进行摘要计算,在 APK 资源很多、性能较差的机器上签名校验会花费较长时间,导致安装速度慢。
完整性保障不够
Meta-INF 目录用来存放签名,自然此目录本身是不计入签名校验过程的,可以随意在这个目录中添加文件,比如一些快速批量打包方案就选择在这个目录中添加渠道文件。
为了解决这两个问题,在 Android 7.0 版本 中引入了全新的 APK Signature Scheme v2。
V2的改进
由于在 v1 仅针对单个 ZIP 条目进行验证,因此,在 APK 签署后可进行许多修改 — 可以移动甚至重新压缩文件。事实上,编译过程中要用到的 ZIPalign 工具就是这么做的,它用于根据正确的字节限制调整 ZIP 条目,以改进运行时性能。而且我们也可以利用这个东西,在打包之后修改 Meta-INF 目录下面的内容,或者修改 ZIP 的注释来实现多渠道的打包,在 v1 签名中都可以校验通过。
v2 签名将验证归档中的所有字节,而不是单个 ZIP 条目,因此,在签署后无法再运行 ZIPalign(必须在签名之前执行)。正因如此,现在,在编译过程中,Google 将压缩、调整和签署合并成一步完成。
v2 签名
v2 签名会在原先 APK 块中增加了一个新的块(签名块),新的块存储了签名、摘要、签名算法、证书链和额外属性等信息,这个块有特定的格式。最终的签名APK其实就有四块:头文件区、v2签名块、中央目录、尾部。下图是v1签名和v2签名的组成。
整个签名块的格式如下:
- size of block,以字节数(不含此字段)计 (uint64)
- 带 uint64 长度前缀的“ID-值”对序列:
- size of block,以字节数计 - 与第一个字段相同 (uint64)
- magic“APK 签名分块 42”(16 个字节)
在多个“ID-值”对中,APK签名信息的 ID 为 0x7109871a,包含的内容如下:
带长度前缀的 signer:
- 带长度前缀的 signed data,包含digests序列,X.509 certificates 序列,additional attributes序列
- 带长度前缀的 signatures(带长度前缀)序列
- 带长度前缀的 public key(SubjectPublicKeyInfo,ASN.1 DER 形式)
- value可能会包含多个 signer,因为Android允许多个签名。
总结一下:一个签名块,可以包含多个ID-VALUE,APK的签名信息会存放在 ID 为 0x7109871a的键值对里。他的内容可以包含多个签名者的签名信息,每个签名信息下包含signed data、signatures、public key,其中,signed data主要存放摘要序列、证书链、额外属性,signatures包含多个签名算法计算出来的签名值,public key表示签名者公钥,用于校验的时候验证签名的。
签名过程
首先,说一下 APK 摘要计算规则,对于每个摘要算法,计算结果如下:
- 将 APK 中文件 ZIP 条目的内容、ZIP 中央目录、ZIP 中央目录结尾按照 1MB 大小分割成一些小块。
- 计算每个小块的数据摘要,数据内容是 0xa5 + 块字节长度 + 块内容。
- 计算整体的数据摘要,数据内容是 0x5a + 数据块的数量 + 每个数据块的摘要内容
总之,就是把 APK 按照 1M 大小分割,分别计算这些分段的摘要,最后把这些分段的摘要在进行计算得到最终的摘要也就是 APK 的摘要。然后将 APK 的摘要 + 数字证书 + 其他属性生成签名数据写入到 APK Signing Block 区块。
@H_447_404@
签名校验过程
接下来我们来看一下v2签名的校验过程,整体大概流程如下图所示。
其中, v2 签名机制是在 Android 7.0 以及以上版本才支持的。因此对于 Android 7.0 以及以上版本,在安装过程中,如果发现有 v2 签名块,则必须走 v2 签名机制,不能绕过。否则降级走 v1 签名机制。v1 和 v2 签名机制是可以同时存在的,其中对于 v1 和 v2 版本同时存在的时候,v1 版本的 Meta_INF 的 .SF 文件属性当中有一个 X-Android-APK-Signed 属性。
X-Android-APK-Signed: 2
之前的渠道包生成方案是通过在 Meta-INF 目录下添加空文件,用空文件的名称来作为渠道的唯一标识。但在新的应用签名方案下 Meta-INF 已经被列入了保护区了,向 Meta-INF 添加空文件的方案会对区块 1、3、4 都会有影响。对于这个问题,可以参考美团多渠道打包总结。
新版v3签名在v2的基础上,仍然采用检查整个压缩包的校验方式。不同的是在签名部分增可以添加新的证书(Attr块)。在这个新块中,会记录我们之前的签名信息以及新的签名信息,以密钥转轮的方案,来做签名的替换和升级。这意味着,只要旧签名证书在手,我们就可以通过它在新的 APK 文件中,更改签名。
v3 签名新增的新块(attr)存储了所有的签名信息,由更小的 Level 块,以链表的形式存储。
其中每个节点都包含用于为之前版本的应用签名的签名证书,最旧的签名证书对应根节点,系统会让每个节点中的证书为列表中下一个证书签名,从而为每个新密钥提供证据来证明它应该像旧密钥一样可信。
签名校验过程
Android 的签名方案,无论怎么升级,都是要确保向下兼容。因此,在引入 v3 方案后,Android 9.0 及更高版本中,可以根据 APK 签名方案,v3 -> v2 -> v1 依次尝试验证 APK。而较旧的平台会忽略 v3 签名并尝试 v2 签名,最后才去验证 v1 签名。
整个验证的过程,如下图:
需要注意的是,对于覆盖安装的情况,签名校验只支持升级,而不支持降级。也就是说设备上安装了一个使用 v1 签名的 APK,可以使用 v2 签名的 APK 进行覆盖安装,反之则不允许。