Android v1、v2、v3簽名詳解 [復制鏈接]

2019-11-29 11:48
一碼到底 閱讀:1338 評論:2 贊:1
Tag:  

Android簽名機制

什么是Android簽名
了解 HTTPS 通信的同學都知道,在消息通信時,必須至少解決兩個問題:一是確保消息來源的真實性,二是確保消息不會被第三方篡改。
同理,在安裝 apk 時,同樣也需要確保 apk 來源的真實性,以及 apk 沒有被第三方篡改。為了解決這一問題,Android官方要求開發者對 apk 進行簽名,而簽名就是對apk進行加密的過程。要了解如何實現簽名,需要了解兩個基本概念:消息摘要、數字簽名和數字證書。
消息摘要
消息摘要(Message Digest),又稱數字摘要(Digital Digest)或數字指紋(Finger Print)。簡單來說,消息摘要就是在消息數據上,執行一個單向的 Hash 函數,生成一個固定長度的Hash值,這個Hash值即是消息摘要。
上面提到的的加密 Hash 函數就是消息摘要算法。它有以下特征:
  • 無論輸入的消息有多長,計算出來的消息摘要的長度總是固定的。
    例如:應用 MD5 算法摘要的消息有128個比特位,用 SHA-1 算法摘要的消息最終有 160 比特位的輸出,SHA-1 的變體可以產生 192 比特位和 256 比特位的消息摘要。一般認為,摘要的最終輸出越長,該摘要算法就越安全。
  • 消息摘要看起來是「隨機的」。
    這些比特看上去是胡亂的雜湊在一起的??梢杂么罅康妮斎雭頇z驗其輸出是否相同,一般,不同的輸入會有不同的輸出,而且輸出的摘要消息可以通過隨機性檢驗。但是,一個摘要并不是真正隨機的,因為用相同的算法對相同的消息求兩次摘要,其結果必然相同;而若是真正隨機的,則無論如何都是無法重現的。因此消息摘要是「偽隨機的」。
  • 消息摘要函數是單向函數,即只能進行正向的信息摘要,而無法從摘要中恢復出任何的消息,甚至根本就找不到任何與原信息相關的信息。
    當然,可以采用強力攻擊的方法,即嘗試每一個可能的信息,計算其摘要,看看是否與已有的摘要相同,如果這樣做,最終肯定會恢復出摘要的消息。但實際上,要得到的信息可能是無窮個消息之一,所以這種強力攻擊幾乎是無效的。
  • 好的摘要算法,沒有人能從中找到「碰撞」?;蛘哒f,無法找到兩條消息,使它們的摘要相同。雖然「碰撞」是肯定存在的(由于長明文生成短摘要的 Hash 必然會產生碰撞)。即對于給定的一個摘要,不可能找到一條信息使其摘要正好是給定的。
正是由于以上特點,消息摘要算法被廣泛應用在「數字簽名」領域,作為對明文的摘要算法。著名的消息摘要算法有 RSA 公司的 MD5 算法和 SHA-1 算法及其大量的變體。SHA-256 是 SHA-1 的升級版,現在 Android 簽名使用的默認算法都已經升級到 SHA-256 了。
正是因為消息摘要具有這種特性,很適合來驗證數據的完整性。比如:在網絡傳輸過程中下載一個大文件 BigFile,我們會同時從網絡下載 BigFile 和 BigFile.md5,BigFile.md5 保存 BigFile 的摘要,我們在本地生成 BigFile 的消息摘要和 BigFile.md5 比較,如果內容相同,則表示下載過程正確。
數字簽名
數字簽名的作用就是保證信息傳輸的完整性、發送者的身份認證、防止交易中的抵賴發生。數字簽名技術是將摘要信息用發送者的私鑰加密,與原文一起傳送給接收者。接收者只有用發送者的公鑰才能解密被加密的摘要信息然后用HASH函數對收到的原文產生一個摘要信息,與解密的摘要信息對比。如果相同,則說明收到的信息是完整的,在傳輸過程中沒有被修改,否則說明信息被修改過,因此數字簽名能夠驗證信息的完整性。
如 RSA 作為數字簽名方案使用時,它的使用流程如下:這種簽名實際上就是用信源的私鑰加密消息,加密后的消息即成了簽體;而用對應的公鑰進行驗證,若公鑰解密后的消息與原來的消息相同,則消息是完整的,否則消息不完整。
RSA正好和公鑰密碼用于消息保密是相反的過程。因為只有信源才擁有自己地私鑰,別人無法重新加密源消息,所以即使有人截獲且更改了源消息,也無法重新生成簽體,因為只有用信源的私鑰才能形成正確地簽體。
同樣信宿只要驗證用信源的公鑰解密的消息是否與明文消息相同,就可以知道消息是否被更改過,而且可以認證消息是否是確實來自意定的信源,還可以使信源不能否認曾經發送的消息。所以 這樣可以完成數字簽名的功能。
但這種方案過于單純,它僅可以保證消息的完整性,而無法確保消息的保密性。而且這種方案要對所有的消息進行加密操作,這在消息的長度比較大時,效率是非常低的,主要原因在于公鑰體制的加解密過程的低效性。所以這種方案一般不可取。
幾乎所有的數字簽名方案都要和快速高效的摘要算法(Hash 函數)一起使用,當公鑰算法與摘要算法結合起來使用時,便構成了一種有效地數字簽名方案。
簽名證書
通過數字簽名技術,確實可以解決可靠通信的問題。一旦驗簽通過,接收者就能確信該消息是期望的發送者發送的,而發送者也不能否認曾經發送過該消息。
大家有沒有注意到,前面講的數字簽名方法,有一個前提,就是消息的接收者必須事先得到正確的公鑰。如果一開始公鑰就被別人篡改了,那壞人就會被你當成好人,而真正的消息發送者給你發的消息會被你視作無效的。而且,很多時候根本就不具備事先溝通公鑰的信息通道。
那么如何保證公鑰的安全可信呢?這就要靠數字證書來解決了。
數字證書是一個經證書授權(Certificate Authentication)中心數字簽名的包含公鑰擁有者信息以及公鑰的文件。數字證書的格式普遍采用的是 X.509 V3 國際標準,一個標準的 X.509 數字證書通常包含以下內容:
  • 證書的發布機構(Issuer):該證書是由哪個機構(CA 中心)頒發的。
  • 證書的有效期(Validity):證書的有效期,或者說使用期限。過了該日期,證書就失效了。
  • 證書所有人的公鑰(Public-Key):該證書所有人想要公布出去的公鑰。
  • 證書所有人的名稱(Subject):這個證書是發給誰的,或者說證書的所有者,一般是某個人或者某個公司名稱、機構的名稱、公司網站的網址等。
  • 證書所使用的簽名算法(Signature algorithm):這個數字證書的數字簽名所使用的加密算法,這樣就可以使用證書發布機構的證書里面的公鑰,根據這個算法對指紋進行解密。
  • 證書發行者對證書的數字簽名(Thumbprint):數字證書的hash 值(指紋),用于保證數字證書的完整性,確保證書沒有被修改過。
數字證書的原理就是在證書發布時,CA 機構會根據簽名算法(Signature algorithm)對整個證書計算其 hash 值(指紋)并和證書放在一起,使用者打開證書時,自己也根據簽名算法計算一下證書的 hash 值(指紋),如果和證書中記錄的指紋對的上,就說明證書沒有被修改過。
可以看出,數字證書本身也用到了數字簽名技術,只不過簽名的內容是整個證書(里面包含了證書所有者的公鑰以及其他一些內容)。與普通數字簽名不同的是,數字證書的簽名者不是隨隨便便一個普通機構,而是 CA 機構。
總結一下,數字簽名和簽名驗證的大體流程如下圖所示:

Android打包流程

整個Android的打包流程如下圖所示:

編譯打包步驟:
1,打包資源文件,生成R.java文件
打包資源的工具是aapt(The Android Asset Packaing Tool)(E:\Documents\Android\sdk\build-tools\25.0.0\aapt.exe)。
在這個過程中,項目中的AndroidManifest.xml文件和布局文件XML都會編譯,然后生成相應的R.java,另外AndroidManifest.xml會被aapt編譯成二進制。
存放在APP的res目錄下的資源,該類資源在APP打包前大多會被編譯,變成二進制文件,并會為每個該類文件賦予一個resource id。對于該類資源的訪問,應用層代碼則是通過resource id進行訪問的。Android應用在編譯過程中aapt工具會對資源文件進行編譯,并生成一個resource.arsc文件,resource.arsc文件相當于一個文件索引表,記錄了很多跟資源相關的信息。
2. 處理aidl文件,生成相應的Java文件
這一過程中使用到的工具是aidl(Android Interface Definition Language),即Android接口描述語言(E:\Documents\Android\sdk\build-tools\25.0.0\aidl.exe)。
aidl工具解析接口定義文件然后生成相應的Java代碼接口供程序調用。如果在項目沒有使用到aidl文件,則可以跳過這一步。
3. 編譯項目源代碼,生成class文件
項目中所有的Java代碼,包括R.java和.aidl文件,都會變Java編譯器(javac)編譯成.class文件,生成的class文件位于工程中的bin/classes目錄下。
4. 轉換所有的class文件,生成classes.dex文件
dx工具生成可供Android系統Dalvik虛擬機執行的classes.dex文件,該工具位于(E:\Documents\Android\sdk\build-tools\25.0.0\dx.bat)。
任何第三方的libraries和.class文件都會被轉換成.dex文件。dx工具的主要工作是將Java字節碼轉成成Dalvik字節碼、壓縮常量池、消除冗余信息等。
5. 打包生成APK文件
所有沒有編譯的資源,如images、assets目錄下資源(該類文件是一些原始文件,APP打包時并不會對其進行編譯,而是直接打包到APP中,對于這一類資源文件的訪問,應用層代碼需要通過文件名對其進行訪問);編譯過的資源和.dex文件都會被apkbuilder工具打包到最終的.apk文件中。
打包的工具apkbuilder位于 android-sdk/tools目錄下。apkbuilder為一個腳本文件,實際調用的是(E:\Documents\Android\sdk\tools\lib)文件中的com.android.sdklib.build.ApkbuilderMain類。
6. 對APK文件進行簽名
一旦APK文件生成,它必須被簽名才能被安裝在設備上。
在開發過程中,主要用到的就是兩種簽名的keystore。一種是用于調試的debug.keystore,它主要用于調試,在Eclipse或者Android Studio中直接run以后跑在手機上的就是使用的debug.keystore。
另一種就是用于發布正式版本的keystore。
7. 對簽名后的APK文件進行對齊處理
如果你發布的apk是正式版的話,就必須對APK進行對齊處理,用到的工具是zipalign(E:\Documents\Android\sdk\build-tools\25.0.0\zipalign.exe)
對齊的主要過程是將APK包中所有的資源文件距離文件起始偏移為4字節整數倍,這樣通過內存映射訪問apk文件時的速度會更快。對齊的作用就是減少運行時內存的使用。
從上圖可以看到,簽名發生在打包過程中的倒數第二步,而且簽名針對的是已經存在的apk包,并不會影響我們寫的代碼。事實也確實是如此,Android的簽名,大致的簽名原理就是對未簽名的apk里面的所有文件計算hash,然后保存起來(MANIFEST.MF),然后在對這些hash計算hash保存起來(CERT.SF),然后在計算hash,然后再通過我們上面生成的keystore里面的私鑰進行加密并保存(CERT.RSA)。

Android簽名方案

Android 系統從誕生到現在的1.0版本,一共經歷了三代應用簽名方案,分別是v1、v2和v3方案。
  • v1 方案:基于 JAR 簽名。
  • v2 方案:APK 簽名方案 v2,在 Android 7.0 引入。
  • v3 方案:APK 簽名方案v3,在 Android 9.0 引入。
其中,v1 到 v2 是顛覆性的,主要是為了解決 JAR 簽名方案的安全性問題,而到了 v3 方案,其實結構上并沒有太大的調整,可以理解為 v2 簽名方案的升級版。
v1 到 v2 方案的升級,對開發者影響是最大的,就是渠道簽署的問題。v2的簽名也是為了讓不同渠道、市場的安裝包有所區別,攜帶渠道的唯一標識,也即是我們俗稱的渠道包。好在各大廠都開源了自己的簽渠道方案,例如:Walle(美團)、VasDolly(騰訊)都是非常優秀的方案。

V1簽名

簽名工具
Android 應用的簽名工具有兩種:jarsigner 和 apksigner。它們的簽名算法沒什么區別,主要是簽名使用的文件不同。它們的區別如下:
  • jarsigner:jdk 自帶的簽名工具,可以對 jar 進行簽名。使用 keystore 文件進行簽名。生成的簽名文件默認使用 keystore 的別名命名。
  • apksigner:Android sdk 提供的專門用于 Android 應用的簽名工具。使用 pk8、x509.pem 文件進行簽名。其中 pk8 是私鑰文件,x509.pem 是含有公鑰的文件。生成的簽名文件統一使用“CERT”命名。
既然這兩個工具都是給 APK 簽名的,那么 keystore 文件和 pk8,x509.pem 他們之間是不是有什么聯系呢?答案是肯定的,他們之間是可以轉化的,這里就不再分析它們是如何進行轉化,網上的例子很多。
還有一個需要注意的知識點,如果我們查看一個keystore 文件的內容,會發現里面包含有一個 MD5 和 SHA1 摘要,這個就是 keystore 文件中私鑰的數據摘要,這個信息也是我們在申請很多開發平臺賬號時需要填入的信息。
簽名過程
首先,我們任意選取一個簽名后的 APK(Sample-release.APK)進行解壓,會得到如下圖所示的文件。

可以發現,在 META-INF 文件夾下有三個文件:MANIFEST.MF、CERT.SF、CERT.RSA。它們就是簽名過程中生成的文件,它們的作用如下。
MANIFEST.MF
該文件中保存的其實就是逐一遍歷 APK 中的所有條目,如果是目錄就跳過,如果是一個文件,就用 SHA1(或者 SHA256)消息摘要算法提取出該文件的摘要然后進行 BASE64 編碼后,作為「SHA1-Digest」屬性的值寫入到 MANIFEST.MF 文件中的一個塊中。該塊有一個「Name」屬性, 其值就是該文件在 APK 包中的路徑。
打開MANIFEST.MF文件,文件內容如下圖:

CERT.SF
打開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 文件用私鑰計算出簽名, 然后將簽名以及包含公鑰信息的數字證書一同寫入 CERT.RSA 中保存。需要注意的是,Android APK 中的 CERT.RSA 證書是自簽名的,并不需要第三方權威機構發布或者認證的證書,用戶可以在本地機器自行生成這個自簽名證書。Android 目前不對應用證書進行 CA 認證。
打開CERT.RSA文件,內容如下圖:

這里看到的都是二進制文件,因為 使用RSA 加密了,所以我們需要用 openssl 命令才能查看其內容,如下所示。
$ openssl pkcs7 -inform DER -in /<文件存放路徑>/Sample-release_new/original/META-INF/CERT.RSA -text -noout -print_certs
執行上面的命令后,得到的內容如下圖:

綜上可以看出,一個完整的簽名過程如下圖:

簽名校驗
簽名驗證是發生在 APK 的安裝過程中,一共分為三步:
  • 檢查 APK 中包含的所有文件,對應的摘要值與 MANIFEST.MF 文件中記錄的值一致。
  • 使用證書文件(RSA 文件)檢驗簽名文件(SF 文件)沒有被修改過。
  • 使用簽名文件(SF 文件)檢驗 MF 文件沒有被修改過。
綜上所述,一個完整的簽名驗證過程如下所示:

V2簽名

APK 簽名方案 v2 是一種全文件簽名方案,該方案能夠發現對 APK 的受保護部分進行的所有更改,從而有助于加快驗證速度并增強完整性保證。通過前面的分析,可以發現 v1 簽名有兩個地方可以改進:
  • 簽名校驗速度慢
    校驗過程中需要對apk中所有文件進行摘要計算,在 APK 資源很多、性能較差的機器上簽名校驗會花費較長時間,導致安裝速度慢。
  • 完整性保障不夠
    META-INF 目錄用來存放簽名,自然此目錄本身是不計入簽名校驗過程的,可以隨意在這個目錄中添加文件,比如一些快速批量打包方案就選擇在這個目錄中添加渠道文件。
為了解決這兩個問題,在 Android 7.0 版本 中引入了全新的 APK Signature Scheme v2。
V2的改進
由于在 v1 僅針對單個 ZIP 條目進行驗證,因此,在 APK 簽署后可進行許多修改 — 可以移動甚至重新壓縮文件。事實上,編譯過程中要用到的 ZIPalign 工具就是這么做的,它用于根據正確的字節限制調整 ZIP 條目,以改進運行時性能。而且我們也可以利用這個東西,在打包之后修改 META-INF 目錄下面的內容,或者修改 ZIP 的注釋來實現多渠道的打包,在 v1 簽名中都可以校驗通過。
v2 簽名將驗證歸檔中的所有字節,而不是單個 ZIP 條目,因此,在簽署后無法再運行 ZIPalign(必須在簽名之前執行)。正因如此,現在,在編譯過程中,Google 將壓縮、調整和簽署合并成一步完成。
v2 簽名
v2 簽名會在原先 APK 塊中增加了一個新的塊(簽名塊),新的塊存儲了簽名、摘要、簽名算法、證書鏈和額外屬性等信息,這個塊有特定的格式。最終的簽名APK其實就有四塊:頭文件區、V2簽名塊、中央目錄、尾部。下圖是V1簽名和V2簽名的組成。

整個簽名塊的格式如下:
  • size of block,以字節數(不含此字段)計 (uint64)
  • 帶 uint64 長度前綴的“ID-值”對序列:
  • size of block,以字節數計 - 與第一個字段相同 (uint64)
  • magic“APK 簽名分塊 42”(16 個字節)
在多個“ID-值”對中,APK簽名信息的 ID 為 0x7109871a,包含的內容如下:
帶長度前綴的 signer:
  • 帶長度前綴的 signed data,包含digests序列,X.509 certificates 序列, additional attributes序列
  • 帶長度前綴的 signatures(帶長度前綴)序列
  • 帶長度前綴的 public key(SubjectPublicKeyInfo,ASN.1 DER 形式)
  • value可能會包含多個 signer,因為Android允許多個簽名。
總結一下:一個簽名塊,可以包含多個ID-VALUE,APK的簽名信息會存放在 ID 為 0x7109871a的鍵值對里。他的內容可以包含多個簽名者的簽名信息,每個簽名信息下包含signed data、signatures、public key,其中,signed data主要存放摘要序列、證書鏈、額外屬性,signatures包含多個簽名算法計算出來的簽名值,public key表示簽名者公鑰,用于校驗的時候驗證簽名的。
簽名過程
首先,說一下 APK 摘要計算規則,對于每個摘要算法,計算結果如下:
  • 將 APK 中文件 ZIP 條目的內容、ZIP 中央目錄、ZIP 中央目錄結尾按照 1MB 大小分割成一些小塊。
  • 計算每個小塊的數據摘要,數據內容是 0xa5 + 塊字節長度 + 塊內容。
  • 計算整體的數據摘要,數據內容是 0x5a + 數據塊的數量 + 每個數據塊的摘要內容
總之,就是把 APK 按照 1M 大小分割,分別計算這些分段的摘要,最后把這些分段的摘要在進行計算得到最終的摘要也就是 APK 的摘要。然后將 APK 的摘要 + 數字證書 + 其他屬性生成簽名數據寫入到 APK Signing Block 區塊。

簽名校驗過程
接下來我們來看一下v2簽名的校驗過程,整體大概流程如下圖所示。

其中, v2 簽名機制是在 Android 7.0 以及以上版本才支持的。因此對于 Android 7.0 以及以上版本,在安裝過程中,如果發現有 v2 簽名塊,則必須走 v2 簽名機制,不能繞過。否則降級走 v1 簽名機制。v1 和 v2 簽名機制是可以同時存在的,其中對于 v1 和 v2 版本同時存在的時候,v1 版本的 META_INF 的 .SF 文件屬性當中有一個 X-Android-APK-Signed 屬性。
X-Android-APK-Signed: 2
之前的渠道包生成方案是通過在 META-INF 目錄下添加空文件,用空文件的名稱來作為渠道的唯一標識。但在新的應用簽名方案下 META-INF 已經被列入了保護區了,向 META-INF 添加空文件的方案會對區塊 1、3、4 都會有影響。對于這個問題,可以參考美團多渠道打包總結。并且V2簽名也存在一些漏洞,具體參考Android簽名漏洞

V3簽名

新版v3簽名在v2的基礎上,仍然采用檢查整個壓縮包的校驗方式。不同的是在簽名部分增可以添加新的證書(Attr塊)。在這個新塊中,會記錄我們之前的簽名信息以及新的簽名信息,以密鑰轉輪的方案,來做簽名的替換和升級。這意味著,只要舊簽名證書在手,我們就可以通過它在新的 APK 文件中,更改簽名。
v3 簽名新增的新塊(attr)存儲了所有的簽名信息,由更小的 Level 塊,以鏈表的形式存儲。
其中每個節點都包含用于為之前版本的應用簽名的簽名證書,最舊的簽名證書對應根節點,系統會讓每個節點中的證書為列表中下一個證書簽名,從而為每個新密鑰提供證據來證明它應該像舊密鑰一樣可信。
簽名校驗過程
Android 的簽名方案,無論怎么升級,都是要確保向下兼容。因此,在引入 v3 方案后,Android 9.0 及更高版本中,可以根據 APK 簽名方案,v3 -> v2 -> v1 依次嘗試驗證 APK。而較舊的平臺會忽略 v3 簽名并嘗試 v2 簽名,最后才去驗證 v1 簽名。
整個驗證的過程,如下圖:

需要注意的是,對于覆蓋安裝的情況,簽名校驗只支持升級,而不支持降級。也就是說設備上安裝了一個使用 v1 簽名的 APK,可以使用 v2 簽名的 APK 進行覆蓋安裝,反之則不允許。關于V3簽名的更多知識,可以參考下面的文章:Android  v3簽名新特性
作者:xiangzhihong
鏈接:https://juejin.im/post/5db830e9518825645f5ad8e5


我來說兩句
您需要登錄后才可以評論 登錄 | 立即注冊
facelist
所有評論(2)
沈號添 2020-2-10 23:40
dddd
回復
moshenghang 2020-2-26 15:44
kai xinni  saif
回復
領先的中文移動開發者社區
18620764416
7*24全天服務
意見反饋:[email protected]

掃一掃關注我們

Powered by Discuz! X3.2© 2001-2019 Comsenz Inc.( 粵ICP備15117877號 )

白沟网供网包牛牛