本文作者： 九心，原文發(fā)布于： 九心說。
前言
最近幫測試做了一點(diǎn)關(guān)于簽名的需求，今天就和各位同學(xué)簡單聊一聊關(guān)于簽名的那些事兒。
如果問到 Android 為什么需要簽名？大家都可能想到官網(wǎng)的解釋：
?Android 系統(tǒng)要求所有 APK 必須先使用證書進(jìn)行數(shù)字簽名，然后才能安裝到設(shè)備上進(jìn)行更新。
?
這是一個(gè)比較模糊的解釋，簡單來說，有了簽名，就可以讓 App 和開發(fā)者綁定。
畢竟，應(yīng)用那么多，別的開發(fā)者也有可能盜用你的代碼，這個(gè)時(shí)候，包名和你相同，代碼和你相同，怎么區(qū)分你的 App 和這些人的 App 不是同一個(gè)呢？
這個(gè)時(shí)候數(shù)字簽名就派上用場了。
1
簽名基礎(chǔ)
想要徹底了解簽名知識(shí)，我們得了解以下知識(shí)：
-
消息摘要
-
數(shù)字簽名
-
加密
-
數(shù)字證書
這一系列的知識(shí)各位可能在學(xué)習(xí)網(wǎng)絡(luò)的時(shí)候或多或少的接觸過。
我們簡單的學(xué)習(xí)一下這些知識(shí)：
1. 消息摘要
消息摘要常常被被稱為數(shù)字摘要或者數(shù)字指紋，定義如下：
?在原來的數(shù)據(jù)基礎(chǔ)上，經(jīng)過一個(gè)單向的 Hash 計(jì)算，得到一個(gè)固定的 Hash 值，這就是消息摘要。
?
常見的摘要算法都有 MD5、SHA-1 和 SHA-256，特點(diǎn)如下：
1. 「 長度固定，與內(nèi)容長度無關(guān)」：比如 MD5 是 128 位、SHA-1 是 160 位、SHA-256 是 256 位。
2. 「 看似隨機(jī)，其實(shí)不隨機(jī)」：同內(nèi)容兩次摘要得出的結(jié)果一致。
3. 「 單向」：只能從原數(shù)據(jù)得出摘要，不能從消息摘要得出原來的數(shù)據(jù)。
4. 「 優(yōu)秀的摘要算法很難 Hash 碰撞」。
基于此，消息摘要常常會(huì)被用來檢查內(nèi)容的完整性。
比如我們下載起點(diǎn)讀書，消息摘要的用法如下：
1. 計(jì)算摘要：App 會(huì)針對(duì)自己的文件信息計(jì)算出一個(gè)數(shù)字摘要比如 123**...**123。
2. 下載App。
3. 驗(yàn)證摘要：對(duì)下載的 App 再次計(jì)算摘要，比如得出的也是 123**...**123，和之前的數(shù)字摘要一對(duì)比，這就代表我從服務(wù)器下載的內(nèi)容是完整的，可以正常使用。
當(dāng)然，上面只涉及了摘要部分，其他過程，我們后面分析。
2. 加密算法
什么是加密？
百科是這么解釋的：
?將明文信息改變?yōu)殡y以讀取的密文內(nèi)容，使之不可讀的過程。只有擁有解密方法的對(duì)象，經(jīng)由解密過程，才能將密文還原為正常可讀的內(nèi)容。
?
所以啊，加密方法得到的密文是可以轉(zhuǎn)變?yōu)槊魑牡模裥畔⒄惴ū热?MD5 得出來的結(jié)果是不可逆的，所以面試官問你們什么是加密算法的時(shí)候，你可不能把 MD5 說進(jìn)去！
加密算法分為兩大類，「 對(duì)稱加密」和「 非對(duì)稱加密」。
2.1 對(duì)稱加密
對(duì)稱加密在加密和解密的時(shí)候使用的同一把鑰匙：
圖片來自《一文徹底搞懂加密、數(shù)字簽名和數(shù)字證書！》
2.2 非對(duì)稱加密
非對(duì)稱加密是使用公鑰/私鑰中的公鑰來加密明文，然后使用對(duì)應(yīng)的私鑰來解密密文的過程：
圖片來自《一文徹底搞懂加密、數(shù)字簽名和數(shù)字證書！》
簡單對(duì)比一下對(duì)稱加密和非對(duì)稱機(jī)密：
| 非對(duì)稱加密 | 對(duì)稱加密 | |
|---|---|---|
| 速度 | 慢 | 快 |
| 效率 | 低 | 高 |
| 安全性 | 高 | 低 |
| 常見算法 | RSADH | AESDESIDEA |
2.3 使用場景
學(xué)過網(wǎng)絡(luò)的同學(xué)應(yīng)該都了解，在 Https 的傳輸過程中，客戶端和服務(wù)端使用非對(duì)稱加密生成對(duì)稱加密的密鑰，然后用對(duì)稱加密傳輸網(wǎng)絡(luò)中的數(shù)據(jù)。
比如我上大學(xué)那會(huì)兒，每個(gè)月的月尾我和我媽的對(duì)話是這樣的：
對(duì)話
網(wǎng)絡(luò)環(huán)境是開放的，萬一這時(shí)，有一個(gè)黑客監(jiān)聽了我和我媽的對(duì)話，過程就變成了這樣：
監(jiān)聽過程
在我發(fā)卡號(hào)的時(shí)候，黑客將我的卡號(hào)改成了他的卡號(hào)，于是我的生活費(fèi)變成了他的生活費(fèi)。
為了避免這種情況，于是我和我媽約定好了，每次發(fā)送前，使用對(duì)稱加密對(duì)消息進(jìn)行加密，接受消息的時(shí)候使用密鑰解密，過程就變成了這樣：
對(duì)稱加密
中間人再也不能獲取到消息了，看似一點(diǎn)問題都沒有，但是我和老媽之間如何確定密鑰呢？
密鑰總要在互聯(lián)網(wǎng)之間進(jìn)行傳輸?shù)模袀鬏斁陀斜恢虚g人截獲的風(fēng)險(xiǎn)，一旦被截獲，錢可就沒了！
為了解決對(duì)稱加密鑰匙傳輸?shù)膯栴}，我和老媽用上了非對(duì)稱加密，像這樣：
非對(duì)稱加密
即使這樣，還是有問題存在：
1. 怎么才能確認(rèn)我獲得的公鑰來自老媽？
2. 如何確定消息確實(shí)來自老媽？
解決這兩個(gè)問題也很簡單，一是數(shù)字簽名，二就是數(shù)字證書。
3. 數(shù)字簽名
數(shù)字簽名的作用是為了消息的完整性。
在非對(duì)稱加密的體系下，消息的發(fā)送過程是這樣的，還是上面的例子：
數(shù)字簽名
數(shù)字簽名的過程是這樣的：
1. 我發(fā)送消息前，利用 Hash 算法針對(duì)數(shù)據(jù)得出一個(gè)摘要。
2. 我使用老媽的公鑰對(duì)摘要內(nèi)容進(jìn)行加密，連同對(duì)稱加密的數(shù)據(jù)一起發(fā)送過去。
3. 老媽接收到消息后，先利用對(duì)稱密鑰對(duì)內(nèi)容解密，再進(jìn)行 Hash 計(jì)算得出摘要。
4. 老媽使用私鑰將摘要內(nèi)容解密，和再次計(jì)算得出的摘要作對(duì)比，一致就代表消息無誤。
上面的這種場景其實(shí)有點(diǎn)不妥，數(shù)字簽名一般用在證書上，協(xié)商好對(duì)稱密鑰以后一般不會(huì)進(jìn)行消息完整性校驗(yàn)了，不過大伙只要了解數(shù)字簽名要來校驗(yàn)消息完整性就好。
截止現(xiàn)在，還有最后一個(gè)問題，我無法確認(rèn)獲取的公鑰確實(shí)來自老媽。
4. 數(shù)字證書
證書的作用很簡單，證明公鑰的身份。
就像在現(xiàn)實(shí)中，大家都是怎么證明自己的身份的？
沒錯(cuò)，是身份證。你有沒有發(fā)現(xiàn)，每張身份證，會(huì)有三種信息：
1. 自身的信息。
2. 置辦身份證的派出所。
3. 有效期。
對(duì)應(yīng)的數(shù)字證書也有很多內(nèi)容：
1. CA：證書的頒發(fā)機(jī)構(gòu)。
2. 證書的有效期。
3. 公鑰。
4. 證書的授予對(duì)象。
CA 將這些內(nèi)容利用 CA 的私鑰進(jìn)行簽名，用戶使用 CA 的公鑰驗(yàn)簽，從而證明公鑰的身份。
常見的證書分為兩種：
1. 簽名證書：由 CA 機(jī)構(gòu)頒發(fā)，絕大部分網(wǎng)站都采用的這種方式。
2. 自簽名證書：由服務(wù)器自己頒發(fā)給自己。
重回之前的例子，老媽只需要將自己的簽名證書發(fā)給我，我就可以獲取她的公鑰，之后就可以正常的通信。
2
Android簽名機(jī)制
在 Android 中，也需要使用數(shù)字證書做數(shù)字簽名，數(shù)字證書中公鑰對(duì)應(yīng)的私鑰由開發(fā)者持有。
關(guān)于私鑰和證書的生成方式，可以查看：
?《Android官方文檔》
https://developer.android.com/studio/publish/app-signing?hl=zh-cn#debug-mode
?
在 Android Studio 中，最終會(huì)生成一個(gè) .jks 的文件，早期 Eclipse 是 .keystore，它們都是用作證書和私鑰的二進(jìn)制文件。
App 如果使用了一種私鑰簽名，另外一個(gè)私鑰簽名的文件將無法安裝或覆蓋老的版本，這樣做是為了防止已經(jīng)安裝的 App 被惡意的第三方覆蓋。
1. Android簽名機(jī)制的異同點(diǎn)
Android 中數(shù)字簽名的生成和普通的數(shù)字簽名并沒有很大的區(qū)別。
但是進(jìn)行數(shù)字簽名的證書可以采用自簽名證書，即不需要權(quán)威證書頒發(fā)機(jī)構(gòu)（CA）來做背書，因?yàn)樗淖饔檬怯脕順?biāo)識(shí)應(yīng)用程序的開發(fā)者，下載的用戶并不需要這個(gè)證書來下載該 App。
2. Debug和Relase的簽名
當(dāng)我們?cè)贗DE中運(yùn)行或調(diào)試項(xiàng)目時(shí)，AS 會(huì)自動(dòng)使用 Android SDK 工具生成的調(diào)試證書為我們的應(yīng)用簽名，路徑為 $HOME/.android/debug.keystore，但是應(yīng)用商店可不接受使用調(diào)試證書發(fā)布的應(yīng)用簽名。
打包Release時(shí)，我們一般會(huì)在 app 模塊中的build.gradle 進(jìn)行配置：
android {
...
signingConfigs {
release {
storeFile file( "release.keystore")
storePassword "******"
keyAlias "******"
keyPassword "******"
}
}
}
這些都是我們生成.jks 或者.keystore需要生成的參數(shù)。
3
簽名方案
目前 Android 支持以下四種應(yīng)用簽名方案：
1. v1方案：基于 JAR 簽名。
2. v2方案：Android 7.0 引入，改動(dòng)大。
3. v3方案：Android 9.0 引入，基于 v2 的升級(jí)。
4. v4方案：Android 11.0 引入，用來支持 ADB 增量 APK 安裝。
1. v1方案
v1 是一個(gè)老生常談的簽名了，簽名過程也很簡單。
我們?nèi)绻x中一個(gè)任意簽名后的 apk 進(jìn)行解壓，會(huì)找到一個(gè)META-INF文件，這個(gè)文件里一般會(huì)有以 MF、SF 和 RSA 結(jié)尾的文件，如圖：
這些文件在 v1 簽名流程中是這樣的：
v1流程
驗(yàn)證過程在 Apk 安裝的過程中：
v1驗(yàn)證
整個(gè)過程清晰明了，但 v1 有兩個(gè)問題：
第一個(gè)問題是簽名校驗(yàn)慢，要針對(duì) Apk 中所有的文件進(jìn)行校驗(yàn)，這會(huì)拖累老設(shè)備的安裝時(shí)間。
第二個(gè)問題是僅針對(duì) ZIP 條目校驗(yàn)，META-INF文件不會(huì)計(jì)入校驗(yàn)過程。這樣會(huì)導(dǎo)致即使我 Apk 已經(jīng)簽過名，工程師也可以移動(dòng)條目順序并重新壓縮，也可以修改 META-INF文件下的內(nèi)容，帶來一些安全隱患，早期的多渠道打包就是在這里做的文章。
2. v2方案
v2 是 Android 簽名方案的一大步，它解決了 v1 遺留的簽名校驗(yàn)慢和完整性的問題。
我們先來看一下 v2 的組成部分：
簽名前和簽名后的 APK
v1 的組成部分其實(shí)就和 Before signing 那一塊兒一樣，v2 多了紅色區(qū)域，我們稱之為APK簽名分塊。
簽名后的各個(gè) APK 部分
從保護(hù)的內(nèi)容來看，v1 僅保護(hù)內(nèi)容1，v2 保護(hù)的區(qū)域有 1、3、4 和 2 的 signed data 區(qū)域，signed data 是 1、3 和 4 得出來的摘要等信息。
簽名過程
就一個(gè) App 而言，它可能有一個(gè)或者多個(gè)簽名者，對(duì)于每個(gè)簽名者而言，都會(huì)進(jìn)行簽名過程。
v2 沒有對(duì)每個(gè)文件都進(jìn)行計(jì)算，而是針對(duì)的所有字節(jié)。它將 1、3 和 4 區(qū)域都拆分成了大小為 1MB 的連續(xù)塊，計(jì)算方式如下：
1. 每個(gè)小塊都按：字節(jié) 0xa5 + 塊字節(jié)長度 + 塊內(nèi)容 進(jìn)行計(jì)算。
2. 每個(gè)1、3 和 4 塊都按：字節(jié) 0xa5 + 塊數(shù) + 小塊摘要 進(jìn)行計(jì)算。
最后，將這些一個(gè)或者多個(gè)簽名者的摘要、證書等信息都打包到 Apk 中。
v2流程
驗(yàn)簽過程
v2 方案的 APK 驗(yàn)證過程是這樣的：
1. 找到APK簽名分塊區(qū)域。
2. 每找到一個(gè)簽名者，都會(huì)驗(yàn)證：簽名算法、信息摘要、證書和公鑰。
3. 所有的簽名者都驗(yàn)證通過了，APK 驗(yàn)證才會(huì)通過。
3. v3方案
v3 方案建立在 v2 的基礎(chǔ)上，目標(biāo)是解決在更新過程中更改簽名密鑰的問題。
所以 APK 簽名分塊中 添加了兩部分內(nèi)容：
1. Proof-of-rotation: 一個(gè)存在替換的所有舊簽名證書的鏈表，根節(jié)點(diǎn)是最舊的證書。
2. SDK 版本支持。
v3 和 v2 的簽名過程和驗(yàn)證過程幾乎一致，就不寫出來了。
4. v4方案
如果同學(xué)們經(jīng)常玩一些主機(jī)游戲，可以發(fā)現(xiàn)，在 PS5 或者 Swtich 上，一些游戲即使沒有安裝完成，我們也可以打開游戲玩一些基本功能，比如我以前常玩的 NBA 2k 系列。
Android 11 中谷歌也新增了 「ADB增量APK安裝」 功能，比如一個(gè) APK 有 2GB，我下載完 50 MB 以后，就可以使用一些基本功能，剩余的文件通過后臺(tái)流式傳輸，不過 Android 11 中的這個(gè)功能是面向 ADB 的。
雖然這個(gè)功能很贊，但是對(duì)簽名方案帶來了一些挑戰(zhàn)，之前的方案都是基于所有文件進(jìn)行校驗(yàn)的，于是推出 Android 第四代簽名方案 v4。
v4 基于 APK 所有的字節(jié)計(jì)算出 Merkle Hash 樹，并將 Merkle 樹的根 Hash、鹽值作為簽名數(shù)據(jù)進(jìn)行包完整性校驗(yàn)，v4 簽名必須單獨(dú)存在 .idsig 文件中，不會(huì)存在于 APK 文件中，所以 apk 文件中仍然需要 v2 或者 v3 簽名。
5. 向下兼容的簽名方案
Android 中的簽名方案是自上而下兼容的，如圖：
APK 驗(yàn)證流程 v4
對(duì)于 Android 11 來說，驗(yàn)證過程是這樣的：
1. 是否支持 v4，v4 驗(yàn)證完了再驗(yàn)證 v3 或者 v2
2. v4 不通過，驗(yàn)證 v3
3. v3 不通過，驗(yàn)證 v2
4. v2 不通過，驗(yàn)證 v1
5. v1 不通過，安裝失敗
對(duì)于 Android 9 來說，就得從 v3 方案開始驗(yàn)證的。
總結(jié)
讀完這篇文章，相信你對(duì) Android 簽名方案有了基礎(chǔ)的了解。
如果文章有不對(duì)的地方，評(píng)論區(qū)見～
參考文章：
《Android v1、v2、v3簽名詳解》
《增量安裝與安卓V4簽名簡介》
《官方文檔》
https://source.android.google.cn/security/apksigning?hl=zh-cn
最后推薦一下我做的網(wǎng)站，玩Android: wanandroid.com，包含詳盡的知識(shí)體系、好用的工具，還有本公眾號(hào)文章合集，歡迎體驗(yàn)和收藏！
：
遵循最新安卓架構(gòu)，做一個(gè)完美的玩Android App
超好的的包體積優(yōu)化教程，真不僅僅是優(yōu)化！
黑科技！讓Native Crash 與ANR無處發(fā)泄！
