目錄
一、什么是apk簽名？
二、為什么需要簽名
三、apk簽名方案
????V1
????V2
????V3
四、apk簽名校驗
五、多渠道打包

---

前言

消息摘要

消息摘要只能保證消息的完整性，并不能保證消息的不可篡改性。

消息摘要（Message Digest），又稱數(shù)字摘要（Digital Digest）或數(shù)字指紋（Finger Print）。簡單來說，消息摘要就是在消息數(shù)據(jù)上，執(zhí)行一個單向的 Hash 函數(shù)，生成一個固定長度的Hash值，這個Hash值即是消息摘要。
加密 Hash 函數(shù)就是消息摘要算法。經典的Hash算法有：MD5 算法、SHA-1 算法、SHA-256，SHA-256 是 SHA-1 的升級版，現(xiàn)在 Android 簽名使用的默認算法都已經升級到 SHA-256 了。

數(shù)字簽名

數(shù)字簽名方案是一種以電子形式存儲消息簽名的方法。一個完整的數(shù)字簽名方案應該由兩部分組成：簽名算法和驗證算法。

幾乎所有的數(shù)字簽名方案都要和快速高效的摘要算法（Hash 函數(shù)）一起使用，當公鑰算法與摘要算法結合起來使用時，便構成了一種有效地數(shù)字簽名方案。

這個過程是：

• 用摘要算法對消息進行摘要。
• 再把摘要值用信源的私鑰加密。

通過以上兩步得到的消息就是所謂的原始信息的數(shù)字簽名，發(fā)送者需要將原始信息和數(shù)字簽名一同發(fā)送給接收者。而接收者在接收到原始信息和數(shù)字簽名后，通過以下 3 步驗證消息的真?zhèn)?#xff1a;

• 先把接收到的原始消息用同樣的摘要算法摘要，形成「準簽體」。
• 使用預先得到的公鑰，將數(shù)字簽名進行解密。
• 比較前兩步所得到的兩段消息是否一致。如果一致，則表明消息確實是期望的發(fā)送者發(fā)的，且內容沒有被篡改過；相反，如果不一致，則表明傳送的過程中一定出了問題，消息不可信。

這種方法使公鑰加密只對消息摘要進行操作，因為一種摘要算法的摘要消息長度是固定的，而且都比較「短」（相對于消息而言），正好符合公鑰加密的要求。這樣效率得到了提高，而其安全性也并未因為使用摘要算法而減弱。

綜上所述，數(shù)字簽名是 非對稱加密技術 + 消息摘要 技術的結合。

公鑰密碼體制（public-key cryptography）
公鑰密碼體制分為三個部分，公鑰、私鑰、加密解密算法，它的加密解密過程如下：

• 加密：通過加密算法和公鑰對內容（或者說明文）進行加密，得到密文。加密過程需要用到公鑰。
• 解密：通過解密算法和私鑰對密文進行解密，得到明文。解密過程需要用到解密算法和私鑰。注意，由公鑰加密的內容，只能由私鑰進行解密，也就是說，由公鑰加密的內容，如果不知道私鑰，是無法解密的。
• 公鑰密碼體制的公鑰和算法都是公開的（這是為什么叫公鑰密碼體制的原因），私鑰是保密的。大家都以使用公鑰進行加密，但是只有私鑰的持有者才能解密。
• 在實際使用中，有需要的人會生成一對公鑰和私鑰，把公鑰發(fā)布出去給別人使用，自己保留私鑰。目前使用最廣泛的公鑰密碼體制是 RSA 密碼體制。

對稱加密算法（symmetric key algorithms）
在對稱加密算法中，加密和解密都是使用的同一個密鑰。因此對稱加密算法要保證安全性的話，密鑰要做好保密，只能讓使用的人知道，不能對外公開。

非對稱加密算法（asymmetric key algorithms）
在非對稱加密算法中，加密使用的密鑰和解密使用的密鑰是不相同的。前面所說的公鑰密碼體制就是一種非對稱加密算法，它的公鑰和是私鑰是不能相同的，也就是說加密使用的密鑰和解密使用的密鑰不同，因此它是一個非對稱加密算法。

RSA 簡介
RSA 密碼體制是一種公鑰密碼體制，公鑰公開，私鑰保密，它的加密解密算法是公開的。由公鑰加密的內容可以并且只能由私鑰進行解密，而由私鑰加密的內容可以并且只能由公鑰進行解密。也就是說，RSA 的這一對公鑰、私鑰都可以用來加密和解密，并且一方加密的內容可以由并且只能由對方進行解密。

• 加密：公鑰加密，私鑰解密的過程，稱為「加密」。
  因為公鑰是公開的，任何公鑰持有者都可以將想要發(fā)送給私鑰持有者的信息進行加密后發(fā)送，而這個信息只有私鑰持有者才能解密。
• 簽名：私鑰加密，公鑰解密的過程，稱為「簽名」。
• 它和加密有什么區(qū)別呢？因為公鑰是公開的，所以任何持有公鑰的人都能解密私鑰加密過的密文，所以這個過程并不能保證消息的安全性，但是它卻能保證消息來源的準確性和不可否認性，也就是說，如果使用公鑰能正常解密某一個密文，那么就能證明這段密文一定是由私鑰持有者發(fā)布的，而不是其他第三方發(fā)布的，并且私鑰持有者不能否認他曾經發(fā)布過該消息。故此將該過程稱為「簽名」。

數(shù)字證書

使用數(shù)字簽名方法的前提，就是消息的接收者必須事先得到正確的公鑰。如果一開始公鑰就被別人篡改了，那壞人就會被你當成好人，而真正的消息發(fā)送者給你發(fā)的消息會被你視作無效的。如何保證公鑰的安全可信呢？這就要靠數(shù)字證書來解決了。

數(shù)字證書是一個經證書授權（Certificate Authentication）中心數(shù)字簽名的包含公鑰擁有者信息以及公鑰的文件。數(shù)字證書的格式普遍采用的是 X.509 V3 國際標準，一個標準的 X.509 數(shù)字證書通常包含以下內容：

• 證書的發(fā)布機構（Issuer）:由哪個機構（CA 中心）頒發(fā)。
• 證書的有效期（Validity）:證書的有效期，或者說使用期限。過了該日期，證書就失效了。
• 證書所有人的公鑰（Public-Key）:證書所有人想要公布出去的公鑰。
• 證書所有人的名稱（Subject）:證書是發(fā)給誰的，或者說證書的所有者，一般是某個人或者某個公司名稱、機構的名稱、公司網站的網址等。
• 證書所使用的簽名算法（Signature algorithm）:這個數(shù)字證書的數(shù)字簽名所使用的加密算法，這樣就可以使用證書發(fā)布機構的證書里面的公鑰，根據(jù)這個算法對指紋進行解密。
• 證書發(fā)行者對證書的數(shù)字簽名（Thumbprint）:該數(shù)字證書的指紋，用于保證數(shù)字證書的完整性，確保證書沒有被修改過。

其原理就是在發(fā)布證書時，CA 機構會根據(jù)簽名算法（Signature algorithm）對整個證書計算其 hash 值（指紋）并和證書放在一起，使用者打開證書時，自己也根據(jù)簽名算法計算一下證書的 hash 值（指紋），如果和證書中記錄的指紋對的上，就說明證書沒有被修改過。
.
數(shù)字證書本身也用到了數(shù)字簽名技術，只不過簽名的內容是整個證書（里面包含了證書所有者的公鑰以及其他一些內容）。與普通數(shù)字簽名不同的是，數(shù)字證書的簽名者不是隨隨便便一個普通機構，而是 CA 機構。
.
一般來說，這些 CA 機構的根證書已經在設備出廠前預先安裝到了你的設備上了。所以，數(shù)字證書可以保證證書里的公鑰確實是這個證書所有者的，或者證書可以用來確認對方的身份?？梢?#xff0c;數(shù)字證書主要是用來解決公鑰的安全發(fā)放問題。

一、什么是apk簽名？

????簽名是摘要與非對稱密鑰加密相相結合的產物，摘要就像內容的一個指紋信息，一旦內容被篡改，摘要就會改變，簽名是摘要的加密結果，摘要改變，簽名也會失效。Android APK簽名也是這個道理，如果APK簽名跟內容對應不起來，Android系統(tǒng)就認為APK內容被篡改了，從而拒絕安裝，以保證系統(tǒng)的安全性。

????應用程序的作者使用自己的私鑰簽名APK文件，并將簽名與公鑰一起發(fā)布到APK中，這個過程稱之為簽名。當應用程序被安裝時，用發(fā)布的公鑰去解析簽名，并與文件的hash進行比對，這個過程叫驗簽。

二、為什么需要簽名

在消息通信時，必須至少解決兩個問題：一是確保消息來源的真實性，二是確保消息不會被第三方篡改。
.
簽名機制主要有兩種用途：

• 使用特殊的key簽名可以獲取到一些不同的權限
• 驗證數(shù)據(jù)保證不被篡改，防止應用被惡意的第三方覆蓋

三、apk簽名方案

Android 現(xiàn)在已經支持三種應用簽名方案：

• v1 方案：基于 JAR 簽名。
• v2 方案：APK 簽名方案 v2，在 Android 7.0 引入。
• v3 方案：APK 簽名方案v3，在 Android 9.0 引入。
• v4 方案：APK 簽名方案v4，在Android11.0引入。

v1 到 v2 是顛覆性的，為了解決 JAR 簽名方案的安全性問題，而到了 v3 方案，其實結構上并沒有太大的調整，可以理解為 v2 簽名方案的升級版，有一些資料也把它稱之為 v2+ 方案。因為這種簽名方案的升級，就是向下兼容的，所以只要使用得當，這個過程對開發(fā)者是透明的。

v1 到 v2 方案的升級，對開發(fā)者影響最大的，就是渠道簽署的問題。在當下這個大環(huán)境下，我們想讓不同渠道、市場的安裝包有所區(qū)別，攜帶渠道的唯一標識，這就是我們俗稱的渠道包。好在各大廠都開源了自己的簽渠道方案，例如：Walle（美團）、VasDolly（騰訊）都是非常優(yōu)秀的方案。

V1

在 META-INF 文件夾下有三個文件：MANIFEST.MF、CERT.SF、CERT.RSA。

MANIFEST.MF
該文件中保存的內容其實就是逐一遍歷 APK 中的所有條目，如果是目錄就跳過，如果是一個文件，就用 SHA1（或者 SHA256）消息摘要算法提取出該文件的摘要然后進行 BASE64 編碼后，作為「SHA1-Digest」屬性的值寫入到 MANIFEST.MF 文件中的一個塊中。該塊有一個「Name」屬性， 其值就是該文件在 APK 包中的路徑。

CERT.SF

• SHA1-Digest-Manifest-Main-Attributes：對 MANIFEST.MF 頭部的塊做 SHA1（或者SHA256）后再用 Base64 編碼
• SHA1-Digest-Manifest：對整個 MANIFEST.MF 文件做 SHA1（或者 SHA256）后再用 Base64 編碼
• SHA1-Digest：對 MANIFEST.MF 的各個條目做 SHA1（或者 SHA256）后再用 Base64 編碼

CERT.RSA
這里會把之前生成的 CERT.SF 文件，用私鑰計算出簽名, 然后將簽名以及包含公鑰信息的數(shù)字證書一同寫入 CERT.RSA 中保存。這里要注意的是，Android APK 中的 CERT.RSA 證書是自簽名的，并不需要這個證書是第三方權威機構發(fā)布或者認證的，用戶可以在本地機器自行生成這個自簽名證書。Android 目前不對應用證書進行 CA 認證。

V1的簽名和校驗過程如下：

V2

v1 簽名有兩個地方可以改進：

• 簽名校驗速度慢。校驗過程中需要對apk中所有文件進行摘要計算，在 APK 資源很多、性能較差的機器上簽名校驗會花費較長時間，導致安裝速度慢。

• 完整性保障不夠。META-INF 目錄用來存放簽名，因此該目錄本身是不計入簽名校驗過程的，可以隨意在這個目錄中添加文件，比如一些快速批量打包方案就選擇在這個目錄中添加渠道文件。
  

V3

四、apk簽名校驗

五、多渠道打包

https://tech.meituan.com/2017/01/13/android-apk-v2-signature-scheme.html

V1簽名的多渠道原理：通過在META-INF目錄下添加空文件，用空文件的名稱來作為渠道的唯一標識，之前在META-INF下添加文件是不需要重新簽名應用的，這樣會節(jié)省不少打包的時間，從而提高打渠道包的速度。

V2簽名的多渠道原理：在APK Signing Block區(qū)域增加ID-value擴展，增加自定義的渠道信息，保存到Apk中。

---

參考：
https://xuanxuanblingbling.github.io/ctf/android/2018/12/30/signature/
https://juejin.im/post/5cd239386fb9a0320f7dfcbe
https://www.jianshu.com/p/9ca1d6f3f083
Android 簽名機制 v1、v2、v3

總結

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

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