前言

最近幫測試做了一點關(guān)于簽名的需求，今天就和各位同學(xué)簡單聊一聊關(guān)于簽名的那些事兒。

如果問到 Android 為什么需要簽名？大家都可能想到官網(wǎng)的解釋：

Android 系統(tǒng)要求所有 APK 必須先使用證書進行數(shù)字簽名，然后才能安裝到設(shè)備上進行更新。

這是一個比較模糊的解釋，簡單來說，有了簽名，就可以讓 App 和開發(fā)者綁定。

畢竟，應(yīng)用那么多，別的開發(fā)者也有可能盜用你的代碼，這個時候，包名和你相同，代碼和你相同，怎么區(qū)分你的 App 和這些人的 App 不是同一個呢？

這個時候數(shù)字簽名就派上用場了。

一、簽名基礎(chǔ)

想要徹底了解簽名知識，我們得了解以下知識：

• 消息摘要
• 數(shù)字簽名
• 加密
• 數(shù)字證書

這一系列的知識各位可能在學(xué)習(xí)網(wǎng)絡(luò)的時候或多或少的接觸過。

我們簡單的學(xué)習(xí)一下這些知識：

1. 消息摘要

消息摘要常常被被稱為數(shù)字摘要或者數(shù)字指紋，定義如下：

在原來的數(shù)據(jù)基礎(chǔ)上，經(jīng)過一個單向的 Hash 計算，得到一個固定的 Hash 值，這就是消息摘要。

常見的摘要算法都有 MD5、SHA-1 和 SHA-256，特點如下：

• 長度固定，與內(nèi)容長度無關(guān)：比如 MD5 是 128 位、SHA-1 是 160 位、SHA-256 是 256 位。
• 看似隨機，其實不隨機：同內(nèi)容兩次摘要得出的結(jié)果一致
• 單向：只能從原數(shù)據(jù)得出摘要，不能從消息摘要得出原來的數(shù)據(jù)
• 優(yōu)秀的摘要算法很難 Hash 碰撞

基于此，消息摘要常常會被用來檢查內(nèi)容的完整性。

比如我們下載起點讀書，消息摘要的用法如下：

• 計算摘要：App 會針對自己的文件信息計算出一個數(shù)字摘要比如 123**...**123
• 下載App
• 驗證摘要：對下載的 App 再次計算摘要，比如得出的也是 123**...**123，和之前的數(shù)字摘要一對比，這就代表我從服務(wù)器下載的內(nèi)容是完整的，可以正常使用

當然，上面值涉及了摘要部分，其他過程，我們后面分析。

2. 加密算法

什么是加密？

百科是這么解釋的：

將明文信息改變?yōu)殡y以讀取的密文內(nèi)容，使之不可讀的過程。只有擁有解密方法的對象，經(jīng)由解密過程，才能將密文還原為正?？勺x的內(nèi)容。

所以啊，加密方法得到的密文是可以轉(zhuǎn)變?yōu)槊魑牡?，像信息摘要算法比?MD5 得出來的結(jié)果是不可逆的，所以面試官問你們什么事加密算法的時候，你可不能把 MD5 說進去！

加密算法分為兩大類，對稱加密和非對稱加密。

2.1 對稱加密

對稱加密在加密和解密的時候使用的同一把鑰匙：

2.2 非對稱加密

非對稱加密是使用公鑰/私鑰中的公鑰來加密明文，然后使用對應(yīng)的私鑰來解密密文的過程：

簡單對比一下對稱加密和非對稱機密：

2.3 使用場景

學(xué)過網(wǎng)絡(luò)的同學(xué)應(yīng)該都了解，在 Https 的傳輸過程中，客戶端和服務(wù)端使用非對稱加密生成對稱加密的密鑰，然后用對稱加密傳輸網(wǎng)絡(luò)中的數(shù)據(jù)。

比如我上大學(xué)那會兒，每個月的月尾我和我媽的對話是這樣的：

網(wǎng)絡(luò)環(huán)境是開放的，萬一這時，有一個黑客監(jiān)聽了我和我媽的對話，過程就變成了這樣：

在我發(fā)卡號的時候，黑客將我的卡號改成了它的卡號，于是我的生活費變成了他的生活費。

為了避免這種情況，于是我和我媽約定好了，每次發(fā)送前，使用對稱加密對消息進行加密，接受消息的時候使用密鑰解密，過程就變成了這樣：

中間人再也不能獲取到消息了，看似一點問題都沒有，但是我和老媽之間如何確定密鑰呢？

密鑰總要在互聯(lián)網(wǎng)之間進行傳輸?shù)?，有傳輸就有被中間人截獲的風(fēng)險，一旦被截獲，錢可就沒了！

為了解決對稱加密鑰匙傳輸?shù)膯栴}，我和老媽用上了非對稱加密，像這樣：

即使這樣，還是有問題存在：

• 怎么才能確認我獲得的公鑰來自老媽？
• 如何確定消息確實來自老媽？

解決這兩個問題也很簡單，一是數(shù)字簽名，二就是數(shù)字證書。

3. 數(shù)字簽名

數(shù)字簽名的作用是為了消息的完整性。

在非對稱加密的體系下，消息的發(fā)送過程是這樣的，還是上面的例子：

數(shù)字簽名的過程是這樣的：

• 我發(fā)送消息前，利用 Hash 算法針對數(shù)據(jù)得出一個摘要
• 我使用老媽的公鑰對摘要內(nèi)容進行加密，連同對稱加密的數(shù)據(jù)一起發(fā)送過去
• 老媽接收到消息后，先利用對稱密鑰對內(nèi)容解密，再進行 Hash 計算得出摘要
• 老媽使用私鑰將摘要內(nèi)容解密，和再次計算得出的摘要作對比，一致就代表消息無誤

上面的這種場景其實有點不妥，數(shù)字簽名一般用在證書上，協(xié)商好對稱密鑰以后一般不會進行消息完整性校驗了，不過大伙只要了解數(shù)字簽名要來校驗消息完整性就好。

截止現(xiàn)在，還有最后一個問題，我無法確認獲取的公鑰確實來自老媽。

4. 數(shù)字證書

證書的作用很簡單，證明公鑰的身份。

就像在現(xiàn)實中，大家都是怎么證明自己的身份的？

沒錯，是身份證。你有沒有發(fā)現(xiàn)，每張身份證，會有三種信息：

• 自身的信息
• 置辦身份證的派出所
• 有效期

對應(yīng)的數(shù)字證書也有很多內(nèi)容：

• CA：證書的頒發(fā)機構(gòu)
• 證書的有效期
• 公鑰
• 證書的授予對象

CA 將這些內(nèi)容利用 CA 的私鑰進行簽名，用戶使用 CA 的公鑰驗簽，從而證明公鑰的身份。

常見的證書分為兩種：

• 簽名證書：由 CA 機構(gòu)頒發(fā)，絕大部分網(wǎng)站都采用的這種方式
• 自簽名證書：由服務(wù)器自己頒發(fā)給自己

重回之前的例子，老媽只需要將自己的簽名證書發(fā)給我，我就可以獲取她的公鑰，之后就可以正常的通信。

二、Android簽名機制

在 Android 中，也需要使用數(shù)字證書做數(shù)字簽名，數(shù)字證書中公鑰對應(yīng)的私鑰由開發(fā)者持有。

在 Android Studio 中，最終會生成一個 .jks 的文件，早期 Eclipse 是 .keystore，它們都是用作證書和私鑰的二進制文件。

App 如果使用了一種私鑰簽名，另外一個私鑰簽名的文件將無法安裝或覆蓋老的版本，這樣做是為了防止已經(jīng)安裝的 App 被惡意的第三方覆蓋。

1. Android簽名機制的異同點

Android 中數(shù)字簽名的生成和普通的數(shù)字簽名并沒有很大的區(qū)別。

但是進行數(shù)字簽名的證書可以采用自簽名證書，即不需要權(quán)威證書頒發(fā)機構(gòu)（CA）來做背書，因為它的作用是用來標識應(yīng)用程序的開發(fā)者，下載的用戶并不需要這個證書來下載該 App。

2. Debug和Relase的簽名

當我們在IDE中運行或調(diào)試項目時，AS 會自動使用 Android SDK 工具生成的調(diào)試證書為我們的應(yīng)用簽名，路徑為 $HOME/.android/debug.keystore，但是應(yīng)用商店可不接受使用調(diào)試證書發(fā)布的應(yīng)用簽名。

打包Release時，我們一般會在 app 模塊中的 build.gradle 進行配置：

android {
 ?  ...
 ?  signingConfigs {
 ? ? ?  release {
 ? ? ? ? ?  storeFile file("release.keystore")
 ? ? ? ? ?  storePassword "******"
 ? ? ? ? ?  keyAlias "******"
 ? ? ? ? ?  keyPassword "******"
 ? ? ?  }
 ?  }
}

這些都是我們生成 .jks 或者 .keystore 需要生成的參數(shù)。

三、簽名方案

目前 Android 支持以下四種應(yīng)用簽名方案：

• v1方案：基于 JAR 簽名
• v2方案：Android 7.0 引入，改動大
• v3方案：Android 9.0 引入，基于 v2 的升級
• v4方案：Android 11.0 引入，用來支持 ADB 增量 APK 安裝

1 v1方案

v1 是一個老生常談的簽名了，簽名過程也很簡單。

我們?nèi)绻x中一個任意簽名后的 apk 進行解壓，會找到一個 META-INF 文件，這個文件里一般會有以 MF、SF 和 RSA 結(jié)尾的文件，如圖：

這些文件在 v1 簽名流程中是這樣的：

驗證過程在 Apk 安裝的過程中：

整個過程清晰明了，但 v1 有兩個問題：

第一個問題是簽名校驗慢，要針對 Apk 中所有的文件進行校驗，這會拖累老設(shè)備的安裝時間。

第二個問題是僅針對 ZIP 條目校驗，META-INF 文件不會計入校驗過程。這樣會導(dǎo)致即使我 Apk 已經(jīng)簽過名，工程師也可以移動條目順序并重新壓縮，也可以修改 META-INF 文件下的內(nèi)容，帶來一些安全隱患，早期的多渠道打包就是在這里做的文章。

2. v2方案

v2 是 Android 簽名方案的一大步，它解決了 v1 遺留的簽名校驗慢和完整性的問題。

我們先來看一下 v2 的組成部分：

v1 的組成部分其實就和 Before signing 那一塊兒一樣，v2 多了紅色區(qū)域，我們稱之為APK簽名分塊。

從保護的內(nèi)容來看，v1 僅保護內(nèi)容1，v2 保護的區(qū)域有 1、3、4 和 2 的 signed data 區(qū)域，signed data 是 1、3 和 4 得出來的摘要等信息。

四、簽名過程

就一個 App 而言，它可能有一個或者多個簽名者，對于每個簽名者而言，都會進行簽名過程。

v2 沒有對每個文件都進行計算，而是針對的所有字節(jié)。它將 1、3 和 4 區(qū)域都拆分成了大小為 1MB 的連續(xù)塊，

計算方式如下：

• 每個小塊都按：字節(jié) 0xa5 + 塊字節(jié)長度 + 塊內(nèi)容 進行計算
• 每個1、3 和 4 塊都按：字節(jié) 0xa5 + 塊數(shù) + 小塊摘要 進行計算

最后，將這些一個或者多個簽名者的摘要、證書等信息都打包到 Apk 中。

驗簽過程：

v2 方案的 APK 驗證過程是這樣的：

• 找到APK簽名分塊區(qū)域
• 每找到一個簽名者，都會驗證：簽名算法、信息摘要、證書和公鑰
• 所有的簽名者都驗證通過了，APK 驗證才會通過

1. v3方案

v3 方案建立在 v2 的基礎(chǔ)上，目標是解決在更新過程中更改簽名密鑰的問題。

所以 APK 簽名分塊中 添加了兩部分內(nèi)容：

• Proof-of-rotation: 一個存在替換的所有舊簽名證書的鏈表，根節(jié)點是最舊的證書
• SDK 版本支持

v3 和 v2 的簽名過程和驗證過程幾乎一致，就不寫出來了。

2. v4方案

如果同學(xué)們經(jīng)常玩一些主機游戲，可以發(fā)現(xiàn)，在 PS5 或者 Swtich 上，一些游戲即使沒有安裝完成，我們也可以打開游戲玩一些基本功能，比如我以前常玩的 NBA 2k 系列。

Android 11 中谷歌也新增了 ADB增量APK安裝 功能，比如一個 APK 有 2GB，我下載完 50 MB 以后，就可以使用一些基本功能，剩余的文件通過后臺流式傳輸，不過 Android 11 中的這個功能是面向 ADB 的。

雖然這個功能很贊，但是對簽名方案帶來了一些挑戰(zhàn)，之前的方案都是基于所有文件進行校驗的，于是推出 Android 第四代簽名方案 v4。

v4 基于 APK 所有的字節(jié)計算出 Merkle Hash 樹，并將 Merkle 樹的根 Hash、鹽值作為簽名數(shù)據(jù)進行包完整性校驗，v4 簽名必須單獨存在 .idsig 文件中，不會存在于 APK 文件中，所以 apk 文件中仍然需要 v2 或者 v3 簽名。

3. 向下兼容的簽名方案

Android 中的簽名方案是自上而下兼容的，如圖：

對于 Android 11 來說，驗證過程是這樣的：

• 是否支持 v4，v4 驗證完了再驗證 v3 或者 v2
• v4 不通過，驗證 v3
• v3 不通過，驗證 v2
• v2 不通過，驗證 v1
• v1 不通過，安裝失敗

對于 Android 9 來說，就得從 v3 方案開始驗證的。

到此這篇關(guān)于Android開發(fā)簽名知識梳理總結(jié)的文章就介紹到這了,更多相關(guān)Android開發(fā)簽名內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論