Android

浅谈程序的数字签名

理论基础

数字签名它是基于非对称密钥加密技术与数字摘要算法技术的应用，它是一个包含电子文件信息以及发送者身份，并能够鉴别发送者身份以及发送信息是否被篡改的一段数字串。

一段数字签名数字串，它包含电子文件经过Hash编码后产生的数字摘要，即一个Hash函数值以及发送者的公钥和私钥三部分内容。发送方通过私钥加密后发送给接收方，接收方使用公钥解密，通过对比解密后的Hash函数值确定数据电文是否被篡改。

数字签名（又称公钥数字签名）是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。

它是一种类似写在纸上的普通的物理签名，但是在使用了公钥加密领域的技术来实现的，用于鉴别数字信息的方法。

数字签名方案是一种以电子形式存储消息签名的方法。一个完整的数字签名方案应该由两部分组成：签名算法和验证算法。

android数字签名

在android的APP应用程序安装过程中，系统首先会检验APP的签名信息，如果发现签名文件不存在或者校验签名失败，系统则会拒绝安装，所以APP应用程序在发布到市场之前一定要进行签名。

在OTA升级中也必须使用到数字签名进行校验，在应用版本迭代必须使用相同的证书签名，不然会生成一个新的应用，导致更新失败。在更新过程中使用相同的证书签名的应用可以共享代码和功能

App安装过程中签名检验的流程：

1、检查 APP中包含的所有文件，对应的摘要值与 MANIFEST.MF 文件中记录的值一致。

2、使用证书文件(RSA 文件)检验签名文件(SF文件)是否被修改过。

3、使用签名文件(SF 文件)检验 MF 文件没有被修改过。

CERT.RSA包含数字签名以及开发者的数字证书。CERT.RSA里的数字签名是指对CERT.SF的摘要采用私钥加密后的数据；

MANIFEST.MF文件中是APP中每个文件名称和摘要SHA256；

CERT.SF则是对MANIFEST.MF的摘要。

android中的数字签名有2个主要作用：

1、能定位消息确实是由发送方签名并发出来的，其他假冒不了发送方的签名。

2、确定消息的完整性，签名它代表文件的特征，文件发生变化，数字签名的数值也会发送变化。

Anroid中的签名证书不需要权威机构认证，一般是开发者的自签名证书。所以签名信息中会包含有开发者信息，在一定程度上可以防止应用被破解二次打包成山寨的APP应用，所以签名信息也是用于对APP包防二次打包的一个校验功能点。

(上图是android studio中自创建签名的界面)

在 Android Studio中通过上图创建签名信息后，最终会生成一个 .jks 的文件，它是用作证书和私钥的二进制文件。

(上图是反编译工具直接查看app的签名信息)，也可以通过jarsigner，jadx，jeb等工具查看app的签名信息。

从上图中可以看到这个APP采用了V1和V2签名信息，Android中的签名目前主要由V1、V2、V3、V4组成的。

v1签名方案：基于 JAR 签名，签名完之后是META-INF 目录下的三个文件：MANIFEST.MF、CERT.SF、CERT.RSA。通过这三个文件校验来确保APP中的每个文件都不被改动。

APK v1的缺点就是META-INF目录下的文件并不在校验范围内，所以之前多渠道打包等都是通过在这个目录下添加文件来实现的。

V2签名方案：它是在Android 7.0系统中引入，为了使 APP可以在 Android 6.0 (Marshmallow) 及更低版本的设备上安装，应先使用 JAR 签名功能对 APP 进行签名，然后再使用 v2 方案对其进行签名。它是一个全文件的签名方案，它能够发现对 APP的受保护部分进行的所有更改，从而有助于加快验证速度并增强完整性保证。

V2签名，它会在 APP文件中插入一个APP签名分块，该分块位于“ZIP 中央目录”部分之前并紧邻该部分。在“APP签名分块”内，v2 签名和签名者身份信息会存储在 APK 签名方案 v2 分块中。

V3签名方案：它是Android 9.0系统中引入，基于 v2签名的升级，Android 9 支持 APK密钥轮替，这使应用能够在 APK 更新过程中更改其签名密钥。为了实现轮替，APK 必须指示新旧签名密钥之间的信任级别。v3 在 APK 签名分块中添加了有关受支持的 SDK 版本和 proof-of-rotation 结构的信息。

下面链接官方对V3签名相关的说明

https://source.android.google.cn/security/apksigning/v3

APK 密钥轮替功能可以参考：

https://developer.android.google.cn/about/versions/pie/android-9.0

V4签名方案：它是在Android 11.0 引入，用来支持 ADB 增量 APK 安装。通过 APK 签名方案 v4 支持与流式传输兼容的签名方案。v4 签名基于根据 APK 的所有字节计算得出的 Merkle 哈希树。

Android 11 将签名存储在单独的 .apk.idsig 文件中。

下面2个链接是官方对V4签名的相关说明

https://source.android.google.cn/security/apksigning/v4

https://developer.android.google.cn/about/versions/11/features

从上面的签名信息截图中，也可以看到android的签名采用的是X.509V3国际标准。

这个标准下约定了签名证书必须包含以下的内容。

1、证书的序列号

2、证书所使用的签名算法

3、证书的发行机构名称，命名规则一般采用X.500格式

4、证书的有效期

5、证书的所有人的名称

6、证书所有人的公开密钥

7、证书发行者对证书的签名

从上图APP的签名信息中数字签名要包含摘要加密算法：MD5、SHA-1、SHA-256

MD5是一种不可逆的加密算法。

SHA1：它是由NISTNSA设计为同DSA一起使用的，它对长度小于264的输入，产生长度为160bit的散列值，因此抗穷举(brute-force)性更好。

SHA-256 是 SHA-1 的升级版，现在 Android 签名使用的默认算法都已经升级到 SHA-256 了。

摘要算法中又涉及到对称加密和非对加密

对称加密就是在加密和解密过程中需要使用同一个密钥

非对称加密使用公钥/私钥中的公钥来加密明文，然后使用对应的私钥来解密密文。

APP中如果没采用加固保护，容易出现二次打包重新签名的山寨APP。

APP中二次打包流程：破解者需要对APK文件做反编译分析，反编译为smali代码，并对某些关键函数或者资源进行修改，再回编译为apk文件并重签名。

常见的对抗二次打包的方案：

1、签名校验

原理：二次打包会篡改签名，通过签名前后的变化可以检测是否被二次打包；但是这种很容易被hook掉。

2、文件校验

原理：二次打包前后apk关键文件hash值比较，判断是否被修改;但是这种很容易被hook掉。

3、核心函数转为jni层实现

原理：java层代码转为jni层实现，jni层代码相对而言篡改难度更大;写大量反射代码降低了开发效率。

window数字签名

Window的数字签名是微软的一种安全保障机制。

Window数字签名中的签名证书用于验证开发者身份真实性、保护代码的完整性。用户下载软件时，能通过数字签名验证软件来源可信，确认软件、代码没有被非法篡改或植入病毒。所以，软件开发者会在软件发行前使用代码签名证书为软件代码添加数字签名。

对于一个Windows的可执行应用程序，签发数字签名的时候需要计算的数据摘要并不会是程序文件的全部数据，而是要排除一些特定区域的数据。而这些区域当然和PE文件结构有关，具体地，不管是签发时还是校验时计算的hash都会排除一个checksum字段、一个Security数据目录字段以及数字签名证书部分的数据。