一文看懂Android签名v1、v2、v3、v4，竟然都v4了？

本文作者：九心，原文发布于：九心说。

前言

最近帮测试做了一点关于签名的需求，今天就和各位同学简单聊一聊关于签名的那些事儿。

如果问到 Android 为什么需要签名？大家都可能想到官网的解释：

?

Android 系统要求所有 APK 必须先使用证书进行数字签名，然后才能安装到设备上进行更新。

?

这是一个比较模糊的解释，简单来说，有了签名，就可以让 App 和开发者绑定。

毕竟，应用那么多，别的开发者也有可能盗用你的代码，这个时候，包名和你相同，代码和你相同，怎么区分你的 App 和这些人的 App 不是同一个呢？

这个时候数字签名就派上用场了。

1

签名基础

想要彻底了解签名知识，我们得了解以下知识：

消息摘要

数字签名

加密

数字证书

这一系列的知识各位可能在学习网络的时候或多或少的接触过。

我们简单的学习一下这些知识：

1. 消息摘要

消息摘要常常被被称为数字摘要或者数字指纹，定义如下：

?

在原来的数据基础上，经过一个单向的 Hash 计算，得到一个固定的 Hash 值，这就是消息摘要。

?

常见的摘要算法都有 MD5、SHA-1 和 SHA-256，特点如下：

1. 「 长度固定，与内容长度无关 」：比如 MD5 是 128 位、SHA-1 是 160 位、SHA-256 是 256 位。

2. 「 看似随机，其实不随机 」：同内容两次摘要得出的结果一致。

3. 「 单向 」：只能从原数据得出摘要，不能从消息摘要得出原来的数据。

4. 「 优秀的摘要算法很难 Hash 碰撞 」。

基于此，消息摘要常常会被用来检查内容的完整性。

比如我们下载起点读书，消息摘要的用法如下：

1. 计算摘要：App 会针对自己的文件信息计算出一个数字摘要比如 123**…**123。

2. 下载App。

3. 验证摘要：对下载的 App 再次计算摘要，比如得出的也是 123**…**123，和之前的数字摘要一对比，这就代表我从服务器下载的内容是完整的，可以正常使用。

当然，上面只涉及了摘要部分，其他过程，我们后面分析。

2. 加密算法

什么是加密？

百科是这么解释的：

?

将明文信息改变为难以读取的密文内容，使之不可读的过程。只有拥有解密方法的对象，经由解密过程，才能将密文还原为正常可读的内容。

?

所以啊，加密方法得到的密文是可以转变为明文的，像信息摘要算法比如 MD5 得出来的结果是不可逆的，所以面试官问你们什么是加密算法的时候，你可不能把 MD5 说进去！

加密算法分为两大类，「 对称加密 」和「 非对称加密 」。

2.1 对称加密

对称加密在加密和解密的时候使用的同一把钥匙：

图片来自《一文彻底搞懂加密、数字签名和数字证书！》

2.2 非对称加密

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

图片来自《一文彻底搞懂加密、数字签名和数字证书！》

简单对比一下对称加密和非对称机密：

	非对称加密	对称加密
速度	慢	快
效率	低	高
安全性	高	低
常见算法	RSADH	AESDESIDEA

2.3 使用场景

学过网络的同学应该都了解，在 Https 的传输过程中，客户端和服务端使用非对称加密生成对称加密的密钥，然后用对称加密传输网络中的数据。

比如我上大学那会儿，每个月的月尾我和我妈的对话是这样的：

对话

网络环境是开放的，万一这时，有一个黑客监听了我和我妈的对话，过程就变成了这样：

监听过程

在我发卡号的时候，黑客将我的卡号改成了他的卡号，于是我的生活费变成了他的生活费。

为了避免这种情况，于是我和我妈约定好了，每次发送前，使用对称加密对消息进行加密，接受消息的时候使用密钥解密，过程就变成了这样：

对称加密

中间人再也不能获取到消息了，看似一点问题都没有，但是我和老妈之间如何确定密钥呢？

密钥总要在互联网之间进行传输的，有传输就有被中间人截获的风险，一旦被截获，钱可就没了！

为了解决对称加密钥匙传输的问题，我和老妈用上了非对称加密，像这样：

非对称加密

即使这样，还是有问题存在：

1. 怎么才能确认我获得的公钥来自老妈？

2. 如何确定消息确实来自老妈？

解决这两个问题也很简单，一是数字签名，二就是数字证书。

3. 数字签名

数字签名的作用是为了消息的完整性。

在非对称加密的体系下，消息的发送过程是这样的，还是上面的例子：

数字签名

数字签名的过程是这样的：

1. 我发送消息前，利用 Hash 算法针对数据得出一个摘要。

2. 我使用老妈的公钥对摘要内容进行加密，连同对称加密的数据一起发送过去。

3. 老妈接收到消息后，先利用对称密钥对内容解密，再进行 Hash 计算得出摘要。

4. 老妈使用私钥将摘要内容解密，和再次计算得出的摘要作对比，一致就代表消息无误。

上面的这种场景其实有点不妥，数字签名一般用在证书上，协商好对称密钥以后一般不会进行消息完整性校验了，不过大伙只要了解数字签名要来校验消息完整性就好。

截止现在，还有最后一个问题，我无法确认获取的公钥确实来自老妈。

4. 数字证书

证书的作用很简单，证明公钥的身份。

就像在现实中，大家都是怎么证明自己的身份的？

没错，是身份证。你有没有发现，每张身份证，会有三种信息：

1. 自身的信息。

2. 置办身份证的派出所。

3. 有效期。

对应的数字证书也有很多内容：

1. CA：证书的颁发机构。

2. 证书的有效期。

3. 公钥。

4. 证书的授予对象。

CA 将这些内容利用 CA 的私钥进行签名，用户使用 CA 的公钥验签，从而证明公钥的身份。

常见的证书分为两种：

1. 签名证书：由 CA 机构颁发，绝大部分网站都采用的这种方式。

2. 自签名证书：由服务器自己颁发给自己。

重回之前的例子，老妈只需要将自己的签名证书发给我，我就可以获取她的公钥，之后就可以正常的通信。

2

Android签名机制

在 Android 中，也需要使用数字证书做数字签名，数字证书中公钥对应的私钥由开发者持有。

关于私钥和证书的生成方式，可以查看：

?

《Android官方文档》

https://developer.android.com/studio/publish/apping?hl=zh-cn#debug-mode

?

在 Android Studio 中，最终会生成一个 .jks 的文件，早期 Eclipse 是 .keystore，它们都是用作证书和私钥的二进制文件。

App 如果使用了一种私钥签名，另外一个私钥签名的文件将无法安装或覆盖老的版本，这样做是为了防止已经安装的 App 被恶意的第三方覆盖。

1. Android签名机制的异同点

Android 中数字签名的生成和普通的数字签名并没有很大的区别。

但是进行数字签名的证书可以采用自签名证书，即不需要权威证书颁发机构（CA）来做背书，因为它的作用是用来标识应用程序的开发者，下载的用户并不需要这个证书来下载该 App。

2. Debug和Relase的签名

当我们在IDE中运行或调试项目时，AS 会自动使用 Android SDK 工具生成的调试证书为我们的应用签名，路径为 $
HOME/.android/debug.keystore ，但是应用商店可不接受使用调试证书发布的应用签名。

打包Release时，我们一般会在 app 模块中的 build.gradle 进行配置：

这些都是我们生成 .jks 或者 .keystore 需要生成的参数。

3

来源：闪念基因