Android签名机制的示例分析

这篇文章主要介绍了Android签名机制的示例分析，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。

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（腾讯）都是非常优秀的方案。

V1签名

签名工具

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 包中的路径。

打开MANIFEST.MF文件，文件内容如下图：

CERT.SF

打开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 认证。

打开CERT.RSA文件，内容如下图：

这里看到的都是二进制文件，因为 使用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 文件没有被修改过。

综上所述，一个完整的签名验证过程如下所示：

V2签名

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 区块。

签名校验过程

接下来我们来看一下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签名

新版v3签名在v2的基础上，仍然采用检查整个压缩包的校验方式。不同的是在签名部分增可以添加新的证书（Attr块）。在这个新块中，会记录我们之前的签名信息以及新的签名信息，以密钥转轮的方案，来做签名的替换和升级。这意味着，只要旧签名证书在手，我们就可以通过它在新的 APK 文件中，更改签名。

v3 签名新增的新块（attr）存储了所有的签名信息，由更小的 Level 块，以链表的形式存储。

其中每个节点都包含用于为之前版本的应用签名的签名证书，最旧的签名证书对应根节点，系统会让每个节点中的证书为列表中下一个证书签名，从而为每个新密钥提供证据来证明它应该像旧密钥一样可信。

签名校验过程

Android 的签名方案，无论怎么升级，都是要确保向下兼容。因此，在引入 v3 方案后，Android 9.0 及更高版本中，可以根据 APK 签名方案，v3 -> v2 -> v1 依次尝试验证 APK。而较旧的平台会忽略 v3 签名并尝试 v2 签名，最后才去验证 v1 签名。
整个验证的过程，如下图：

需要注意的是，对于覆盖安装的情况，签名校验只支持升级，而不支持降级。也就是说设备上安装了一个使用 v1 签名的 APK，可以使用 v2 签名的 APK 进行覆盖安装，反之则不允许。

感谢你能够认真阅读完这篇文章，希望小编分享的“Android签名机制的示例分析”这篇文章对大家有帮助，同时也希望大家多多支持亿速云，关注亿速云行业资讯频道，更多相关知识等着你来学习!