Android簽名機制

原文地址：www.jianshu.com/p/fa0e2273f…

不少人只知道開發完以後簽名發佈，簽名就生成一個keystore文件就行，而不太清楚具體的簽名流程，如今我就在這邊簡單過一遍流程。 本章節只講流程，不會詳細的去分析簽名的源碼，而且可能某些細節說得不對，但整體流程確定就是那麼一回事，若是有不對的地方還但願有大佬可以指點。

一.概念

開始以前咱們先來簡單瞭解幾個重要的概念，有助於理解android的簽名流程。

1.加密

數據加密的基本過程就是對原來爲明文的文件或數據按某種算法進行處理，使其成爲不可讀的一段代碼，一般稱爲"密文"，使其只能在輸入相應的密鑰以後才能顯示出原本內容，經過這樣的途徑來達到保護數據不被非法人竊取、閱讀的目的。 加密通常分爲對稱加密和非對稱加密。 通常非對稱加密更爲安全，而通常非對稱加密的操做是用公鑰進行加密，接收端用私鑰進行解密。

2.消息摘要

又稱數字摘要或數字指紋。簡單來講就是任意長度數據通過單向的HASH函數，生成一個固定長度的HASH值。也就是通過算法處理後的一個固定長度的數據。

3.數字簽名

數字簽名的做用就是保證信息傳輸的完整性、發送者的身份認證、防止交易中的抵賴發生。數字簽名技術是將摘要信息用發送者的私鑰加密，與原文一塊兒傳送給接收者。接收者只有用發送者的公鑰才能解密被加密的摘要信息而後用HASH函數對收到的原文產生一個摘要信息，與解密的摘要信息對比。若是相同，則說明收到的信息是完整的，在傳輸過程當中沒有被修改，不然說明信息被修改過，所以數字簽名可以驗證信息的完整性。 和加密相比正好返過來，是用私鑰加密，用公鑰解密。

4.數字證書

數字證書就是互聯網通信中標誌通信各方身份信息的一串數字。簡單來講就是能證實通訊方的身份，能肯定和我通訊的是你，而不是某個假冒你的人。 假如你這邊把應用用私鑰簽名，把簽名後的文件和公鑰都發給接收端。可是若是中間有人攔截，把文件換了，從新用本身的私鑰簽名，再換對應的公鑰發給接收端。接收端依舊能正常校驗成功，難道這就說明這個文件是正確的嗎？因此才須要數字證書來證實這個公鑰來自於真正的發送端。

二. 簽名過程

單單這樣講這些概念，仍是有點難以理解，咱們就用簽名的各個步驟來加深上面的每一個概念。

1. android簽名的工具

android有兩種簽名工具jarsigner和signapk。jarsigner在JDK裏面，apksigner在build-tools裏面，具體的路徑能夠自行百度，由於我不敢保證全部版本的路徑是固定不變的。 jarsigner會生成keystore，也就是咱們用AS的簽名能生成keystore。signapk能生成pk8和pem。這兩方也是能夠轉換的。

2. 簽名和校驗大概流程

按抽象來講（這是按個人理解，也行細節上有些差異），簽名和校驗的大概過程是，發送者把文件用算法生成摘要，再用私鑰對摘要進行加密，把證書、文件、加密串、公鑰發給接收端。接收端獲取到以後，根據證書認真發送者身份，用公鑰對加密串進行解密，再對文件也用算法生成摘要，對比解密以後的信息和摘要的信息是否相同。網上有張圖挺形象的描述這個過程。

3. android簽名生成的三個文件

對代碼簽名以後會生成三個文件：MANIFEST.MF、CERT.SF和CERT.RSA。 若是你解壓apk或者反編譯apk的話會看到一個META-INF文件夾，打開裏面就包含這3個文件

這三個文件是在簽名過程當中生成的。 這裏就抽象講講生成過程，不說源碼，網上也不少講這3個文件的生成代碼。

（1）MANIFEST.MF

MANIFEST.MF的內容是全部文件進行SHA-1（這是一個Hash算法）以後再base64編碼以後的值。去遍歷全部文件，一個一個文件夾遍歷，要是有文件，就SHA-1再base64。不管你每一個文件長度怎樣，每一個文件都會生成一個固定長度的值，再把這些值一行一行記錄下來（固然除了全部文件還有其餘的屬性，這個能夠自行百度）。

能夠看出這個過程就是一個獲取摘要的過程，把不固定長度的文件生成固定長度的字符串。

（2）CERT.SF

其實就是將MANIFEST.MF文件按必定規則再進行SHA-1以後再base64。

SHA1-Digest-Manifest屬性是對整個MANIFEST.MF文件作SHA1再base64生成的串。 以後的每一個SHA1-Digest是對MANIFEST.MF的各個條目作SHA1再用base64。 因此這個過程仍是一個獲取摘要的過程。

（3）CERT.RSA

能夠看出CERT.RSA不一樣於上邊兩個文件，是一個加密串。 CERT.RSA包含了不少東西。CERT.SF文件用私鑰加密，而後把數字證書，公鑰等一塊兒組合在一塊兒生成CERT.RSA。 能夠看出這是一個用私鑰加密的過程。

4. 簽名驗證的過程

安裝的時候，會驗證這三個文件，判斷是否完整，這個其實很好理解。 咱們通常會經歷過這樣的一種狀況，咱們手機已經安裝過一個文件，若是用不一樣的簽名就會安裝出錯，若是使用相同的簽名就能覆蓋安裝。 安裝時先會去查找是否已安裝過相同的包名的應用，而後拿到證書指紋和要安裝應用的證書指紋進行判斷，相同的話說明是同一個應用。 至於指紋證書的原理我也不是很懂，在網上看到有人說是jks中X509證書的摘要信息，也有說是證書發行者對證書的數字簽名。 而這些信息會存在CERT.RSA中，因此這個校驗過程是在校驗CERT.RSA的時候操做的。

大概的一個簽名和驗證的過程基本就是這樣。