标签：文件 公钥 摘要 RSA CERT 概述 签名 Android
转载地址：http://www.jishudog.com/6010/html
一、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签名做对比。
自己的理解：
1.RSA非对称加密的过程，分别有公钥和私钥，可以粗浅的理解为公钥只能把关键信息转化为密文，如果想把密文转变为明文，需要私钥来进行解密
2.如何利用上面的功能实现一下两个需求
- a.银行app，在手机上看到某张卡的银行密码
手机端分别生成公钥和私钥，给服务器发请求的时候把公钥发过去，服务器用公钥对密码进行加密，返回客户端后，客户端用私钥解密后展示给客户
- b.Android签名认证
Android打包的时候，
摘要文件（MANIFEST.MF）经过计算 摘要签名文件（CERT.SF） 这个时候把这个摘要签名文件当作公钥生成的密文（其实并不是），直接用私钥进行解密，就会生成私钥解密后的文件（其实就是Cert.RSA签名文件）,把这个签名文件和公钥一起放在package里面
安装包验证的时候，会用公钥对签名文件进行解密（其实就是公钥加密）就能生成未修改的CERT.SF，再和当前cert.sf进行对比，一致的话就说明未修改
标签：文件,公钥,摘要,RSA,CERT,概述,签名,Android 来源： https://blog.csdn.net/qq_37596427/article/details/117076626
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。