Android应用程序签名过程分析

在正式解释Android应用程序签名过程之前，作为铺垫，还得先讲讲最基本的一些概念。

非对称加密算法

非对称加密算法需要两个密钥：公开密钥（简称公钥）和私有密钥（简称私钥）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密；如果用私钥对数据进行加密，那么只有用对应的公钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

非对称加密算法是数字签名和数字证书的基础，大家非常熟悉的RSA就是非对称加密算法的一种实现。

消息摘要算法

消息摘要算法（Message Digest Algorithm）是一种能产生特殊输出格式的算法，其原理是根据一定的运算规则对原始数据进行某种形式的信息提取，被提取出的信息就被称作原始数据的消息摘要。著名的摘要算法有RSA公司的MD5算法和SHA-1算法及其大量的变体。

消息摘要的主要特点有：

1）无论输入的消息有多长，计算出来的消息摘要的长度总是固定的。例如应用MD5算法摘要的消息有128个比特位，用SHA-1算法摘要的消息最终有160比特位的输出。

2）一般来说（不考虑碰撞的情况下），只要输入的原始数据不同，对其进行摘要以后产生的消息摘要也必不相同，即使原始数据稍有改变，输出的消息摘要便完全不同。但是，相同的输入必会产生相同的输出。

3）具有不可逆性，即只能进行正向的信息摘要，而无法从摘要中恢复出任何的原始消息。

数字签名和数字证书

其实数字签名的概念很简单。大家知道，要确保可靠通信，必须要解决两个问题：首先，要确定消息的来源确实是其申明的那个人；其次，要保证信息在传递的过程中不被第三方篡改，即使被篡改了，也可以发觉出来。

所谓数字签名，就是为了解决这两个问题而产生的，它是对前面提到的非对称加密技术与数字摘要技术的一个具体的应用。

对于消息的发送者来说，先要生成一对公私钥对，将公钥给消息的接收者。

如果消息的发送者有一天想给消息接收者发消息，在发送的信息中，除了要包含原始的消息外，还要加上另外一段消息。这段消息通过如下两步生成：

1）对要发送的原始消息提取消息摘要；

2）对提取的信息摘要用自己的私钥加密。

通过这两步得出的消息，就是所谓的原始信息的数字签名。

而对于信息的接收者来说，他所收到的信息，将包含两个部分，一是原始的消息内容，二是附加的那段数字签名。他将通过以下三步来验证消息的真伪：

1）对原始消息部分提取消息摘要，注意这里使用的消息摘要算法要和发送方使用的一致；

2）对附加上的那段数字签名，使用预先得到的公钥解密；

3）比较前两步所得到的两段消息是否一致。如果一致，则表明消息确实是期望的发送者发的，且内容没有被篡改过；相反，如果不一致，则表明传送的过程中一定出了问题，消息不可信。

通过这种所谓的数字签名技术，确实可以有效解决可靠通信的问题。如果原始消息在传送的过程中被篡改了，那么在消息接收者那里，对被篡改的消息提取的摘要肯定和原始的不一样。并且，由于篡改者没有消息发送方的私钥，即使他可以重新算出被篡改消息的摘要，也不能伪造出数字签名。

所以，综上所述，数字签名其实就是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。

不知道大家有没有注意，前面讲的这种数字签名方法，有一个前提，就是消息的接收者必须要事先得到正确的公钥。如果一开始公钥就被别人篡改了，那坏人就会被你当成好人，而真正的消息发送者给你发的消息会被你视作无效的。而且，很多时候根本就不具备事先沟通公钥的信息通道。那么如何保证公钥的安全可信呢？这就要靠数字证书来解决了。

所谓数字证书，一般包含以下一些内容：

• 证书的发布机构（Issuer）
• 证书的有效期（Validity）
• 消息发送方的公钥
• 证书所有者（Subject）
• 数字签名所使用的算法
• 数字签名

可以看出，数字证书其实也用到了数字签名技术。只不过要签名的内容是消息发送方的公钥，以及一些其它信息。但与普通数字签名不同的是，数字证书中签名者不是随随便便一个普通的机构，而是要有一定公信力的机构。这就好像你的大学毕业证书上签名的一般都是德高望重的校长一样。一般来说，这些有公信力机构的根证书已经在设备出厂前预先安装到了你的设备上了。所以，数字证书可以保证数字证书里的公钥确实是这个证书的所有者的，或者证书可以用来确认对方的身份。数字证书主要是用来解决公钥的安全发放问题。

综上所述，总结一下，数字签名和签名验证的大体流程如下图所示：

Android应用程序签名流程

大家知道，Android采用的是开放的生态系统，任何人都可以开发和发布应用程序给别人使用。不像iOS，在没有被破解的情况下只能通过App Store安装应用，Android在打开了“Unknow Sources”选项后，可以安装任何来源的应用程序，可以是第三方市场，可以是自己开发的应用，也可以从论坛下载。

那么问题来了，对于有一些不怀好意的人，完全可以拿到一个原生的应用，然后加入一些恶意的代码，再发布出去，诱使别人去安装，达到不可告人的目的。

有没有什么办法可以防止应用程序在传送的过程中被第三方恶意篡改呢？Google因此引入了应用程序签名机制。

它是如何工作的呢？我们先来看看签名前后，一个apk文件到底发生了哪些变化。

首先，在没签名之前，apk文件内的目录结构是这样的：

而签名之后，会变成这样：

可以看到，多出来了一个META-INF目录。可以肯定的是，签名的机关就在这个目录中，里面有三个文件：

其实，在Android的源代码里包含了一个工具，可以对apk文件进行签名，具体的代码位置在build\tools\signapk目录下，通过分析其中的SignApk.java文件，可以大致了解签名的过程。其流程大致有如下几步：

1）打开待签名的apk文件（由于apk其实是一个用zip压缩的文件，其实就是用zip解压整个apk文件），逐一遍历里面的所有条目，如果是目录就跳过，如果是一个文件，就用SHA1（或者SHA256）消息摘要算法提取出该文件的摘要然后进行BASE64编码后，作为“SHA1-Digest”属性的值写入到MANIFEST.MF文件中的一个块中。该块有一个“Name”属性，其值就是该文件在apk包中的路径。

2）计算这个MANIFEST.MF文件的整体SHA1值，再经过BASE64编码后，记录在CERT.SF主属性块（在文件头上）的“SHA1-Digest-Manifest”属性值值下。

然后，再逐条计算MANIFEST.MF文件中每一个块的SHA1，并经过BASE64编码后，记录在CERT.SF中的同名块中，属性的名字是“SHA1-Digest”。

3）把之前生成的 CERT.SF文件， 用私钥计算出签名, 然后将签名以及包含公钥信息的数字证书一同写入  CERT.RSA  中保存。CERT.RSA是一个满足PKCS7格式的文件，可以通过openssl工具来查看签名证书的信息。在Ubuntu或者在Windows上使用Cygwin，敲入以下命令：

openssl pkcs7 -inform DER -in CERT.RSA -noout -print_certs –text

可以得到如下输出：

下面我们来看看，如果apk文件被篡改后会发生什么。

首先，如果你改变了apk包中的任何文件，那么在apk安装校验时，改变后的文件摘要信息与MANIFEST.MF的检验信息不同，于是验证失败，程序就不能成功安装。

其次，如果你对更改的过的文件相应的算出新的摘要值，然后更改MANIFEST.MF文件里面对应的属性值，那么必定与CERT.SF文件中算出的摘要值不一样，照样验证失败。

最后，如果你还不死心，继续计算MANIFEST.MF的摘要值，相应的更改CERT.SF里面的值，那么数字签名值必定与CERT.RSA文件中记录的不一样，还是失败。

那么能不能继续伪造数字签名呢？不可能，因为没有数字证书对应的私钥。

所以，如果要重新打包后的应用程序能再Android设备上安装，必须对其进行重签名。

总结

1）Android应用程序签名只是用来解决发布的应用不被别人篡改的，其并不会对应用程序本身进行加密，这点不同于Windows Phone和iOS。

2）Android并不要求所有应用程序的签名证书都由可信任CA的根证书签名，通过这点保证了其生态系统的开放性，所有人都可以用自己生成的证书对应用程序签名。

3）如果想修改一个已经发布的应用程序，哪怕是修改一张图片，都必须对其进行重新签名。但是，签原始应用的私钥一般是拿不到的（肯定在原始应用程序开发者的手上，且不可能公布出去），所以只能用另外一组公私钥对，生成一个新的证书，对重打包的应用进行签名。所以重打包的apk中所带证书的公钥肯定和原始应用不一样。同时，在手机上如果想安装一个应用程序，应用程序安装器会先检查相同包名的应用是否已经被安装过，如果已经安装过，会继续判断已经安装的应用和将要安装的应用，其所携带的数字证书中的公钥是否一致。如果相同，则继续安装；而如果不同，则会提示用户先卸载前面已安装的应用。通过这种方式来提示用户，前后两个应用是不同开发者签名的，可能有一个是李鬼。