Android签名与认证详细分析之一(CERT.RSA剖析)

释放双眼,带上耳机,听听看~!

一、Android签名概述
导语:Android的签名机制是Android保证系统安全的三大机制(权限管理、签名认证、沙箱机制)之一,签名机制要做的只有一件事,就是保证文件的完整性,文件的完整性就是APK在经发布者发布之后,APK内的各个文件都不会被篡改。为了保证这个完整性,就需要采用密码学里面的非对称加密,用私钥对文件内容进行加密,检验的时候用公钥解密,能对应起来,就表明没有被篡改。(非对称加密的内容请自行搜索)又因为,直接对APK内容进行加密的话,APK内容太多了,所以需要先对其做一个摘要处理。所以总结起来就是先做摘要,后用私钥加密。

我们已经知道的是:Android对每一个Apk文件都会进行签名,在Apk文件安装时,系统会对其签名信息进行比对,判断程序的完整性,从而决定该Apk文件是否可以安装,在一定程度上达到安全的目的。

给定一个Apk文件,解压,可以看到一个META-INFO文件夹,在该文件夹下有三个文件:分别为MANIFEST.MF、CERT.SF和CERT.RSA。这三个文件分别表征以下含义:

(1)MANIFEST.MF:这是摘要文件。程序遍历Apk包中的所有文件(entry),对非文件夹非签名文件的文件,逐个用SHA1生成摘要信息,再用Base64进行编码。如果你改变了apk包中的文件,那么在apk安装校验时,改变后的文件摘要信息与MANIFEST.MF的检验信息不同,于是程序就不能成功安装。

说明:这是Android签名验证过程的第一步,保证每个APK包内的每个文件与MANIFEST.MF中的摘要值一一对应,修改某个文件内容,必须修改MANFEST.MF文件中的摘要值,使他们对应起来。

(2)CERT.SF:这是对摘要的签名文件。对前一步生成的MANIFEST.MF,对MANIFEST.MF中的每一条内容分别进行SHA1计算,然后再用Base64编码转换。此外,把MANIFEST.MF的内容也进行SHA1计算,并且计算BASE64编码。将上述内容写入CERT.SF文件中。

说明:这是签名认证过程的第二步,这一步做的是多第一步得到的签名文件的摘要,比如第一步中对文件和MANIFEST.MF摘要都改了,这一步中MANIFEST.MF的摘要值也要修改,否则就对应不起来。

所以,前面这两步,做的都是摘要,是为第三步骤做准备的,第三步骤才是最重要的。

(3)CERT.RSA文件中保存了公钥、所采用的加密算法等信息,此外重要的,还包括对CERT.SF中的内容的用私钥进行加密之后的值。

说明:在这一步,即使开发者修改了程序内容,并生成了新的摘要文件,MANIFEST.MF能与内容对应起来,CERT.SF也能与内容对应起来,但是攻击者没有开发者的私钥,所以不能生成正确的签名文件(CERT.RSA)。系统在对程序进行验证的时候,用开发者公钥对不正确的签名文件进行解密,得到的结果对应不起来,所以不能通过检验,不能成功安装文件。

结论:从上面的总结可以看出,META-INFO里面的说那些文件环环相扣,从而保证Android程序的安全性。(只是防止开发者的程序不被攻击者修改,如果开发者的公私钥对对攻击者得到或者开发者开发出攻击程序,Android系统都无法检测出来。)

参考文章:http://www.blogjava.net/zh-weir/archive/2011/07/19/354663.html

二、在Eclipse下配置App的签名信息
对App进行签名的方式一般有以下几种:通过Google提供的签名工具,通过某些开发者开发的签名工具或者通过Eclipse提供的签名方法,但一般而言,他们都是在下层调用Google提供的签名工具,所以签名的方法都相同。

例如,在Eclipse下面配置签名信息时,可以设置开发者信息:

具体参考文章:http://blog.csdn.net/zuolongsnail/article/details/6444197(上图来源于该文章)

说明:从上图可以看出,在Eclipse中,可以设置开发者的详细信息。在其他的签名工具中,可能会直接调用其他签名信息。

值得注意的是,在设置签名信息的时候,会有如下图所示的步骤:

请暂且记住这里有认证指纹信息:MD5和SHA1。由于这一步骤是在编译生成Apk文件之前进行的,所以,说明这里的MD5和SHA1与程序的内容毫无关系,只与开发者的公私钥对等开发信息有关。

我们自己设置签名信息之后开发程序并签名,得到的签名信息经过keytool.exe解析结果如下:

说明:由上图可以发现,解析结果中的MD5和SHA1与上面得到的MD5,SHA1是相同的。

三、同一个公司的不同App的签名有关系吗?
我们有一个疑问,许多互联网大公司会开发许多官方的移动应用,那么这些应用的签名信息是否相同呢,他们所用的公私钥对是否都是一样的?我们对Tencent公司的QQ,QQ空间,微信三款产品进行解析,得到下面的结果和结论。

1、使用keytool.exe
使用Java提供的keytool.exe工具对三款产品的签名情况(CERT.RSA文件)进行解析,情况如下所示。

微信:

QQ:

QQ空间:

说明:从上面的三幅图可以看出,虽然同为Tencent的三款产品,但是他们的所有者信息、签发人信息等都不尽相同,尽管他们都表示了腾讯公司或者Tencent等信息。因为这是开发者自己设置的,而且微信和QQ属于不同的事业部,办公地点不同,所以他们的签名信息不同也就不足为奇了。

2、自己写应用提取
自己写程序从CERT.RSA提取出公钥信息和证书中的签名信息(对开发者信息的签名,例如姓名,公司,国家等。。。),情况如下:

由于都是一些字符,且很多,所以只取开始和结束的几位比特做一说明:

微信:

公钥:c05f……..5e9f

签名:3082….1949

QQ:

公钥:a15e……..3695

签名:3082……..2049

QQ空间:

公钥:82d………..445

签名:3082……..1677

说明:由于三款App的开发者设置的签名信息几乎不同,使用的公私钥对都不同,所以这里取出来的公钥和签名信息几乎不同。唯一相同的是三款App的签名的开始一些比特,可能是因为有的信息相同,具体不得而知。

四、同一款App的不同版本签名信息有关系吗?
为了说明这个问题,我们对QQ的两个版本做了检测,情况如下:

QQ4.7.0:

公钥:a15e……..3695

签名:3082……..2049

QQ4.6.2:
公钥:a15e……..3695

签名:3082……..2049

说明:QQ的两个不同版本,从CERT.RSA文件中取出的公钥和签名信息,完全相同。说明QQ开发团队始终使用的是一个相同的公私钥对。当然,他们对于不同的版本使用不同的公私钥对也是可以的,也是可能的。这种可能性发生在他们主动更改公私钥对的情况下,也可能发生在他们用不同的环境进行签名的情况下。
五、可以修改META-INFO文件夹下的文件吗?
(1)CERT.RSA,CERT.SF的文件名可以修改。
我们把CERT.SF的文件名改成CERT1.SF,把CERT.RSA的文件名改成CERT1.RSA,原来的Apk文件可以被成功安装。

说明:Android系统在检测的时候,不会一定要找到CERT这种文件名,是按照文件类型来检测的。但是,如果.RSA文件与.SF文件的名字不同,那么就不能成功安装。

(2)添加自己的CERT.SF和CERT.RSA文件到META-INFO文件夹下面,不能成功。
说明:在(1)的基础上,我们执行(2)操作,不能成功安装,这是因为Android系统找不到摘要文件与(2)中添加上的两个文件进行对应。

六、不同的签名应用,得到的结果可能不同。
用Eclipse签名的Apk文件,解析CERT.RSA文件之后得到的结果如下:

用Dodo Apktools签名后的Apk文件解析之后结果如下:

说明:用Dodo签名的解析文件多了后面的扩展部分,但总体内容不变。

七、应用商店用什么方式检测官方版?
豌豆荚推出的洗白白功能很受欢迎,那么他们是如何辨别App的是否是官方出品的呢?

根据搜集到的资料,他们CEO说是这样实现的:将商店里的App与官网上的App签名做对比。

人已赞赏
Android文章

Android系统编译所使用的命令

2019-11-12 13:05:32

Android文章

Android防止双击/多次点击,多次点击启动多个相同界面的问题

2019-11-13 15:25:49

个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
有新消息 消息中心
搜索