Android应用签名

传统签名
数字签名技术是将信息摘要用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的信息摘要，然后接收者用相同的Hash函数对收到的原文产生一个信息摘要，与解密的信息摘要做比对。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改；不同则说明信息被修改过，因此数字签名能保证信息的完整性。并且由于只有发送者才有加密摘要的私钥，所以我们可以确定信息一定是发送者发送的。

APK签名
APK的签名是基于传统签名机制的扩展。APK发行商通过把APK内容的摘要用自己的私钥进行加密后得到签名内容，再把签名内容和自身公钥信息（证书）打包到APK中。APK安装时会进行验签流程，如果验签不过则安装失败。对于APK来说，APK的签名可以唯一确定发行商的身份，并且可以防止攻击者冒用发行商的行为。

公私钥
下面是四个APK编译签名所用到的公私钥。
Media.pk8
Media.x509.pem
Platform.pk8
Platform.x509.pem
Shared.pk8
Shared.x509.pem
Testkey.pk8
Testkey.x509.pem
其中，pk8文件为私钥格式，不可读，pem格式就是我们通常说的“公钥”，该文件是可读的。公钥x509.pem文件实际是一个满足X509格式的证书，包含：
1、X.509版本号：指出该证书使用了哪种版本的X.509标准，版本号会影响证书中的一些特定信息。目前的版本是3。
2、证书持有人的公钥：包括证书持有人的公钥、算法(指明密钥属于哪种密码系统)的标识符和其他相关的密钥参数。
3、证书的序列号：由CA给予每一个证书分配的唯一的数字型编号，当证书被取消时，实际上是将此证书序列号放入由CA签发的CRL（Certificate Revocation List证书作废表，或证书黑名单表）中。这也是序列号唯一的原因。
4、主题信息：证书持有人唯一的标识符(或称DN-distinguished name)这个名字在 Internet上应该是唯一的。DN由许多部分组成，看起来象这样：
CN=Bob Allen, OU=Total Network Security Division
O=Network Associates, Inc.
C=US
这些信息指出该科目的通用名、组织单位、组织和国家或者证书持有人的姓名、服务处所等信息。
5、证书的有效期：证书起始日期和时间以及终止日期和时间；指明证书在这两个时间内有效。
6、认证机构：证书发布者，是签发该证书的实体唯一的CA的X.509名字。使用该证书意味着信任签发证书的实体。(注意：在某些情况下，比如根或顶级CA证书，发布者自己签发证书)
7、发布者的数字签名：这是使用发布者私钥生成的签名，以确保这个证书在发放之后没有被撰改过。
8、签名算法标识符：用来指定CA签署证书时所使用的签名算法。算法标识符用来指定CA签发证书时所使用的公开密钥算法和HASH算法。

BEGIN CERTIFICATE和END CERTIFICATE中间的内容为证书实体，该部分内容采用BASE64编码的。Android 代码解析出的签名实际就是该证书实体，导出packages.xml。查找使用platform签名的应用签名内容与上图platform.x509.pem文件BASE解码的16进制内容一致。综上所述，APK的签名不是指传统密码学中的签名（明文经私钥处理得到的数据），而是指用来验证应用发行商身份的公钥信息。

APK签名过程分析
APK编译时会自动执行签名打包流程，运行SignApk.jar对Apk进行签名。
SignApk签名源码目录：\build\tools\signapk\src\com\android\signapk。签名流程图如下：
1.生成MANIFEST.MF文件
遍历APK的文件清单，为每个文件生成SHA1（现有大部分为SHA256）摘要值。
2.生成CERT.SF文件
遍历MANIFEST.MF文件中每个条目生成SHA1摘要值（这里说的条目包含“Name ：” + “SHA1-Digest”的内容，而非对第一步生成的摘要值再做摘要），再对MANIFEST.MF整体文件进行摘要。
3.生成CERT.RSA文件
对CERT.SF用应用发行商的私钥签名生成签名数据，再把章节2中的x509.pem文件（包含公钥信息）组合用DER编码成CERT.RSA文件。（CERT.RSA文件本身满足x509证书，包含各种公钥信息，用openssl命令可以解析，而解析内容并不包含CERT.SF的签名）

APK安装验签过程分析
APK安装时的验签过程是签名过程的逆向处理。该部分流程代码主要集中在PackageManagerService中。
应用安装需要满足下述3点条件才能安装成功：
1、文件(除META-INF目录外的文件)的摘要值等于MANIFEST.MF中的各SHA-1值。
攻击者拿到APK文件修改某一个文件（如修改class.dex）,会导致应用安装失败，确保除META-INF的文件（MANIFEST.MF,CERT.SF,CERT.RSA）未被篡改
2、MANIFEST.MF文件及各子项的摘要值等于CERT.SF中各项摘要值
如果攻击者修改了某一个文件（如修改class.dex），并采用同样方式生成MANIFEST.MF文件，CERT.SF的内容会校验不过，会导致安装失败，可以确保MANIFEST.MF未被篡改。
3、公钥（CERT.SF） == CERT.RSA/DSA对SF文件的签名
从条件2中进一步，如果攻击者进一步修改CERT.SF文件（修改class.dex文件的同时，修改MANIFEST.MF,CERT.SF的值），会导致CERT.RSA对CERT.SF文件进行验签失败，导致安装失败。要想验签成功，攻击者需要用生成公钥信息代替CERT.RSA的公钥信息部分内容，并生成相应的CERT.SF签名值，这样一来，这个应用的签名就不是来自原有厂商的。
综上所述，签名可以表明应用发行商的身份，非原有发行商的个人或机构在没有厂商私钥的情况下无法仿冒该应用。

签名分类
当前应用使用的签名有4套签名，分别为 testkey、shared、platform、media。应用使用需要在Android.mk中显示声明的LOCAL_CERTIFICATE 的值（比如使用platform签名，LOCAL_CERTIFICATE = platform，默认为testkey签名）。
这四种签名的实际应用如下：
Platform：我们通常所说的系统签名，之所以这么叫，是因为系统（可以理解成包名为android的应用，在packages.xml中有声明）用的就是platform签名，应用签名如果跟系统签名一致，在权限授予、shared uid上会有特权，故把platform签名成为系统签名。一般核心的系统应用如Settings、手机管家等都是platform签名。
Shared：该APK 可以声明（android.uid.shared）安装成功，与home/contacts进程共享数据
media：该APK可以声明（android.media）安装成功，共享media数据。
Testkey：普通签名，默认使用

其他参考链接：
证书Certificate以及android打包签名
http://blog.csdn.net/lintcgirl/article/details/52814529
Android签名机制之—签名过程详解
http://www.2cto.com/kf/201512/455388.html