轉載地址：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進行對比，一致的話就說明未修改

?

?

?

?

?

總結

以上是生活随笔為你收集整理的Android签名概述的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。