浅谈程序的数字签名

理论基础

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

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

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

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

android数字签名

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

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

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

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

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

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

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

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

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的数字签名是微软的一种安全保障机制。

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

(查看某程序的数字签名信息)

从上面截图中看到了摘要算法用到sha1和sha256。

由于SHA-256更强的安全性，现在SHA-256已经作为代码签名证书的行业标准签名算法。

从上图中看到程序拥有2个签名信息，也就是双签名机制。

双签名就是对一个软件做两次签名，先进行SHA1签名，之后再进行SHA2签名的做法就叫做双签名。双签名需要一张支持SHA1和SHA2算法的代码签名证书，利用具备双签名功能的工具导入申请的代码签名证书对软件或应用程序进行双签名，签发后的软件或应用程序就支持SHA1和SHA2签名算法。

Windows10要求使用SHA2算法签名，而Windows7（未更新补丁的）因其兼容性只能使用SHA1算法签名，那么使用一张支持双签SHA1和SHA2算法的代码签名证书就可以实现。

软件签名校验的流程图

（实现判断程序是否有签名功能）

代码实现可以通过映射文件方式，然后去安装PE文件结构去读取，读取到可选头中的数据目录表，通过判断数据目录表中

的IMAGE_DIRECTORY_ENTRY_SECURITY的虚拟地址和大小不为空，那么就表示改应用程序有签名，因为数据签名都是存在在这个字段中。

同样如果要将某个应用程序的签名信息给抹除了，也是一样的思路，将数据目录表中的IMAGE_DIRECTORY_ENTRY_SECURITY的大小和地址都设置为0即可。

小结

数字签名不管是在android端还是window端，它都是一种应用程序的身份标志，在安全领域中对应用程序的数字签名校验是一个很常见的鉴别真伪的一个手段。

现在很多杀毒的厂商也都是通过这个数字签名维度，作为一个该应用程序是否可信程序的校验，虽然一些安全杀毒厂商签完名后还是误 毒，那这只能找厂商开白名单了。

阅读完毕