Android簽名機制---簽名過程

標籤：md5   概念   image   detail   xxxx   詳細   並且   cert   而且   

大神文章：http://blog.csdn.net/jiangwei0910410003/article/details/50402000

一、知識點

1、資料摘要(資料指紋)、簽名檔案，認證檔案

2、jarsign工具簽名和signapk工具簽名

3、keystore檔案和pk8檔案，x509.pem檔案的關係

4、如何手動的簽名apk

二、前提

首先來看一下資料摘要，簽名檔案，認證檔案的知識點

1、資料摘要

這個知識點很好理解，百度百科即可，其實他也是一種演算法，就是對一個資料來源進行一個演算法之後得到一個摘要，也叫作資料指紋，不同的資料來源，資料指紋肯定不一樣，就和人一樣。

訊息摘要演算法（Message Digest Algorithm）是一種能產生特殊輸出格式的演算法，其原理是根據一定的運算規則對未經處理資料進行某種形式的資訊提取，被提取出的資訊就被稱作未經處理資料的訊息摘要。
著名的摘要演算法有RSA公司的MD5演算法和SHA-1演算法及其大量的變體。
訊息摘要的主要特點有：
1）無論輸入的訊息有多長，計算出來的訊息摘要的長度總是固定的。例如應用MD5演算法摘要的訊息有128個位元位，用SHA-1演算法摘要的訊息最終有160位元位的輸出。
2）一般來說（不考慮碰撞的情況下），只要輸入的未經處理資料不同，對其進行摘要以後產生的訊息摘要也必不相同，即使未經處理資料稍有改變，輸出的訊息摘要便完全不同。但是，相同的輸入必會產生相同的輸出。
3）具有無法復原性，即只能進行正向的資訊摘要，而無法從摘要中恢複出任何的原始訊息。

 

2、簽名檔案和認證

簽名檔案和認證是成對出現了，二者不可分離，而且我們後面通過源碼可以看到，這兩個檔案的名字也是一樣的，只是尾碼名不一樣。

其實數位簽章的概念很簡單。大家知道，要確保可靠通訊，必須要解決兩個問題：首先，要確定訊息的來源確實是其申明的那個人；其次，要保證資訊在傳遞的過程中不被第三方篡改，即使被篡改了，也可以發覺出來。
所謂數位簽章，就是為瞭解決這兩個問題而產生的，它是對前面提到的非對稱式加密技術與數字摘要技術的一個具體的應用。
對於訊息的寄件者來說，先要產生一對公私密金鑰對，將公開金鑰給訊息的接收者。
如果訊息的寄件者有一天想給訊息接收者發訊息，在發送的資訊中，除了要包含原始的訊息外，還要加上另外一段訊息。這段訊息通過如下兩步產生：
1）對要發送的原始訊息提取訊息摘要；
2）對提取的資訊摘要用自己的私密金鑰加密。
通過這兩步得出的訊息，就是所謂的原始資訊的數位簽章。
而對於資訊的接收者來說，他所收到的資訊，將包含兩個部分，一是原始的訊息內容，二是附加的那段數位簽章。他將通過以下三步來驗證訊息的真偽：
1）對原始訊息部分提取訊息摘要，注意這裡使用的訊息摘要演算法要和發送方使用的一致；
2）對附加上的那段數位簽章，使用預先得到的公開金鑰解密；
3）比較前兩步所得到的兩段訊息是否一致。如果一致，則表明訊息確實是期望的寄件者發的，且內容沒有被篡改過；相反，如果不一致，則表明傳送的過程中一定出了問題，訊息不可信。
通過這種所謂的數位簽章技術，確實可以有效解決可靠通訊的問題。如果原始訊息在傳送的過程中被篡改了，那麼在訊息接收者那裡，對被篡改的訊息提取的摘要肯定和原始的不一樣。並且，由於篡改者沒有訊息發送方的私密金鑰，即使他可以重新算出被篡改訊息的摘要，也不能偽造出數位簽章。
所以，綜上所述，數位簽章其實就是只有資訊的寄件者才能產生的別人無法偽造的一段數字串，這段數字串同時也是對資訊的寄件者發送資訊真實性的一個有效證明。
不知道大家有沒有注意，前面講的這種數位簽章方法，有一個前提，就是訊息的接收者必須要事先得到正確的公開金鑰。如果一開始公開金鑰就被別人篡改了，那壞人就會被你當成好人，而真正的訊息寄件者給你發的訊息會被你視作無效的。而且，很多時候根本就不具備事先溝通公開金鑰的資訊通道。那麼如何保證公開金鑰的安全可信呢？這就要靠數位憑證來解決了。
所謂數位憑證，一般包含以下一些內容：
認證的發布機構（Issuer）
認證的有效期間（Validity）
訊息發送方的公開金鑰
認證所有者（Subject）
數位簽章所使用的演算法
數位簽章
可以看出，數位憑證其實也用到了數位簽章技術。只不過要簽名的內容是訊息發送方的公開金鑰，以及一些其它資訊。但與普通數位簽章不同的是，數位憑證中籤名者不是隨隨便便一個普通的機構，而是要有一定公信力的機構。這就好像你的大學畢業認證上籤名的一般都是德高望重的校長一樣。一般來說，這些有公信力機構的根憑證已經在裝置出廠前預先安裝到了你的裝置上了。所以，數位憑證可以保證數位憑證裡的公開金鑰確實是這個認證的所有者的，或者認證可以用來確認對方的身份。數位憑證主要是用來解決公開金鑰的安全發放問題。
綜上所述，總結一下，數位簽章和簽名驗證的大體流程如所示：

3、jarsign和signapk工具

瞭解到完了簽名中的三個檔案的知識點之後，下面繼續來看看Android中籤名的兩個工具：jarsign和signapk

關於這兩個工具開始的時候很容易混淆，感覺他們兩到底有什麼區別嗎？

其實這兩個工具很好理解，jarsign是Java本生內建的一個工具，他可以對jar進行簽名的。而signapk是後面專門為了Android應用程式apk進行簽名的工具，他們兩的簽名演算法沒什麼區別，主要是簽名時使用的檔案不一樣，這個就要引出第三個問題了。

 

4、keystore檔案和pk8，x509.pem檔案的區別

我們上面瞭解到了jarsign和signapk兩個工具都可以進行Android中的簽名，那麼他們的區別在於簽名時使用的檔案不一樣

jarsign工具簽名時使用的是keystore檔案

signapk工具簽名時使用的是pk8,x509.pem檔案

 

三、簽名詳解

 簽名後的apk會多出，MANIFEST.MF、xxxx.DSA（dsa是密碼編譯演算法，不同的密碼編譯演算法尾碼不同）、xxxxxx.sf。

1.把apk中除了以上三種檔案都進行一次SHA-1演算法，擷取摘要資訊後再用base64進行編碼之後寫入MANIFEST.MF檔案。

2.xxx.SF做了：

1》計算這個MANIFEST.MF檔案的整體SHA1值，再經過BASE64編碼後，記錄在CERT.SF主屬性塊（在檔案頭上）的“SHA1-Digest-Manifest”屬性值值下

2》逐條計算MANIFEST.MF檔案中每一個塊的SHA1，並經過BASE64編碼後，記錄在CERT.SF中的同名塊中，屬性的名字是“SHA1-Digest

3.xxxxx.DSA是認證

我們看到，這裡會把之前產生的 CERT.SF檔案， 用私密金鑰計算出簽名, 然後將簽名以及包含公開金鑰資訊的數位憑證一同寫入  CERT.RSA  中儲存。CERT.RSA是一個滿足PKCS7格式的檔案。

四、為何要這麼來簽名

上面我們就介紹了簽名apk之後的三個檔案的詳細內容，那麼下面來總結一下，Android中為何要用這種方式進行加密簽名，這種方加密是不是最安全的呢？下面我們來分析一下，如果apk檔案被篡改後會發生什麼。

首先，如果你改變了apk包中的任何檔案，那麼在apk安裝校正時，改變後的檔案摘要資訊與MANIFEST.MF的檢驗資訊不同，於是驗證失敗，程式就不能成功安裝。
其次，如果你對更改的過的檔案相應的算出新的摘要值，然後更改MANIFEST.MF檔案裡面對應的屬性值，那麼必定與CERT.SF檔案中算出的摘要值不一樣，照樣驗證失敗。
最後，如果你還不死心，繼續計算MANIFEST.MF的摘要值，相應的更改CERT.SF裡面的值，那麼數位簽章值必定與CERT.RSA檔案中記錄的不一樣，還是失敗。
那麼能不能繼續偽造數位簽章呢？不可能，因為沒有數位憑證對應的私密金鑰。
所以，如果要重新打包後的應用程式能再Android裝置上安裝，必須對其進行重簽名。

從上面的分析可以得出，只要修改了Apk中的任何內容，就必須重新簽名，不然會提示安裝失敗，當然這裡不會分析，後面一篇文章會注重分析為何會提示安裝失敗。

五、知識點梳理

1、資料指紋，簽名檔案，認證檔案的含義

1》資料指紋就是對一個資料來源做SHA/MD5演算法，這個值是唯一的

2》簽名檔案技術就是：資料指紋+RSA演算法

3》認證檔案中包含了公開金鑰資訊和其他資訊

4》在Android簽名之後，其中SF就是簽名檔案，RSA就是認證檔案我們可以使用openssl來查看RSA檔案中的認證資訊和公開金鑰資訊

2、我們瞭解了Android中的簽名有兩種方式：jarsigner和signapk 這兩種方式的區別是：

1》jarsigner簽名時，需要的是keystore檔案，而signapk簽名的時候是pk8,x509.pem檔案

2》jarsigner簽名之後的SF和RSA檔案名稱預設是keystore的別名，而signapk簽名之後檔案名稱是固定的:CERT

3》Eclipse中我們在跑Debug程式的時候，預設用的是jarsigner方式簽名的，用的也是系統預設的debug.keystore簽名檔案

4》keystore檔案和pk8,x509.pem檔案之間可以互相轉化

Android簽名機制---簽名過程