本篇內(nèi)容介紹了“Android簽名機(jī)制是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

成都創(chuàng)新互聯(lián)致力于互聯(lián)網(wǎng)網(wǎng)站建設(shè)與網(wǎng)站營(yíng)銷，提供成都網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、網(wǎng)站開發(fā)、seo優(yōu)化、網(wǎng)站排名、互聯(lián)網(wǎng)營(yíng)銷、微信小程序開發(fā)、公眾號(hào)商城、等建站開發(fā)，成都創(chuàng)新互聯(lián)網(wǎng)站建設(shè)策劃專家，為不同類型的客戶提供良好的互聯(lián)網(wǎng)應(yīng)用定制解決方案，幫助客戶在新的全球化互聯(lián)網(wǎng)環(huán)境中保持優(yōu)勢(shì)。

什么是Android簽名

了解 HTTPS 通信的同學(xué)都知道，在消息通信時(shí)，必須至少解決兩個(gè)問題：一是確保消息來源的真實(shí)性，二是確保消息不會(huì)被第三方篡改。

同理，在安裝 apk 時(shí)，同樣也需要確保 apk 來源的真實(shí)性，以及 apk 沒有被第三方篡改。為了解決這一問題，Android官方要求開發(fā)者對(duì) apk 進(jìn)行簽名，而簽名就是對(duì)apk進(jìn)行加密的過程。要了解如何實(shí)現(xiàn)簽名，需要了解兩個(gè)基本概念：消息摘要、數(shù)字簽名和數(shù)字證書。

消息摘要

消息摘要（Message Digest），又稱數(shù)字摘要（Digital Digest）或數(shù)字指紋（Finger Print）。簡(jiǎn)單來說，消息摘要就是在消息數(shù)據(jù)上，執(zhí)行一個(gè)單向的 Hash 函數(shù)，生成一個(gè)固定長(zhǎng)度的Hash值，這個(gè)Hash值即是消息摘要。

上面提到的的加密 Hash 函數(shù)就是消息摘要算法。它有以下特征：

無論輸入的消息有多長(zhǎng)，計(jì)算出來的消息摘要的長(zhǎng)度總是固定的。例如：應(yīng)用 MD5 算法摘要的消息有128個(gè)比特位，用 SHA-1 算法摘要的消息最終有 160 比特位的輸出，SHA-1 的變體可以產(chǎn)生 192 比特位和 256 比特位的消息摘要。一般認(rèn)為，摘要的最終輸出越長(zhǎng)，該摘要算法就越安全。

消息摘要看起來是「隨機(jī)的」。這些比特看上去是胡亂的雜湊在一起的?？梢杂么罅康妮斎雭頇z驗(yàn)其輸出是否相同，一般，不同的輸入會(huì)有不同的輸出，而且輸出的摘要消息可以通過隨機(jī)性檢驗(yàn)。但是，一個(gè)摘要并不是真正隨機(jī)的，因?yàn)橛孟嗤乃惴▽?duì)相同的消息求兩次摘要，其結(jié)果必然相同；而若是真正隨機(jī)的，則無論如何都是無法重現(xiàn)的。因此消息摘要是「?jìng)坞S機(jī)的」。

消息摘要函數(shù)是單向函數(shù)，即只能進(jìn)行正向的信息摘要，而無法從摘要中恢復(fù)出任何的消息，甚至根本就找不到任何與原信息相關(guān)的信息。當(dāng)然，可以采用強(qiáng)力攻擊的方法，即嘗試每一個(gè)可能的信息，計(jì)算其摘要，看看是否與已有的摘要相同，如果這樣做，最終肯定會(huì)恢復(fù)出摘要的消息。但實(shí)際上，要得到的信息可能是無窮個(gè)消息之一，所以這種強(qiáng)力攻擊幾乎是無效的。

好的摘要算法，沒有人能從中找到「碰撞」?；蛘哒f，無法找到兩條消息，使它們的摘要相同。雖然「碰撞」是肯定存在的（由于長(zhǎng)明文生成短摘要的 Hash 必然會(huì)產(chǎn)生碰撞）。即對(duì)于給定的一個(gè)摘要，不可能找到一條信息使其摘要正好是給定的。

正是由于以上特點(diǎn)，消息摘要算法被廣泛應(yīng)用在「數(shù)字簽名」領(lǐng)域，作為對(duì)明文的摘要算法。著名的消息摘要算法有 RSA 公司的 MD5 算法和 SHA-1 算法及其大量的變體。SHA-256 是 SHA-1 的升級(jí)版，現(xiàn)在 Android 簽名使用的默認(rèn)算法都已經(jīng)升級(jí)到 SHA-256 了。

正是因?yàn)橄⒄哂羞@種特性，很適合來驗(yàn)證數(shù)據(jù)的完整性。比如：在網(wǎng)絡(luò)傳輸過程中下載一個(gè)大文件 BigFile，我們會(huì)同時(shí)從網(wǎng)絡(luò)下載 BigFile 和 BigFile.md5，BigFile.md5 保存 BigFile 的摘要，我們?cè)诒镜厣?BigFile 的消息摘要和 BigFile.md5 比較，如果內(nèi)容相同，則表示下載過程正確。

數(shù)字簽名

數(shù)字簽名的作用就是保證信息傳輸?shù)耐暾?、發(fā)送者的身份認(rèn)證、防止交易中的抵賴發(fā)生。數(shù)字簽名技術(shù)是將摘要信息用發(fā)送者的私鑰加密，與原文一起傳送給接收者。接收者只有用發(fā)送者的公鑰才能解密被加密的摘要信息然后用HASH函數(shù)對(duì)收到的原文產(chǎn)生一個(gè)摘要信息，與解密的摘要信息對(duì)比。如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，否則說明信息被修改過，因此數(shù)字簽名能夠驗(yàn)證信息的完整性。

如 RSA 作為數(shù)字簽名方案使用時(shí)，它的使用流程如下：這種簽名實(shí)際上就是用信源的私鑰加密消息，加密后的消息即成了簽體；而用對(duì)應(yīng)的公鑰進(jìn)行驗(yàn)證，若公鑰解密后的消息與原來的消息相同，則消息是完整的，否則消息不完整。

RSA正好和公鑰密碼用于消息保密是相反的過程。因?yàn)橹挥行旁床艙碛凶约旱厮借€，別人無法重新加密源消息，所以即使有人截獲且更改了源消息，也無法重新生成簽體，因?yàn)橹挥杏眯旁吹乃借€才能形成正確地簽體。

同樣信宿只要驗(yàn)證用信源的公鑰解密的消息是否與明文消息相同，就可以知道消息是否被更改過，而且可以認(rèn)證消息是否是確實(shí)來自意定的信源，還可以使信源不能否認(rèn)曾經(jīng)發(fā)送的消息。所以 這樣可以完成數(shù)字簽名的功能。

但這種方案過于單純，它僅可以保證消息的完整性，而無法確保消息的保密性。而且這種方案要對(duì)所有的消息進(jìn)行加密操作，這在消息的長(zhǎng)度比較大時(shí)，效率是非常低的，主要原因在于公鑰體制的加解密過程的低效性。所以這種方案一般不可取。

幾乎所有的數(shù)字簽名方案都要和快速高效的摘要算法（Hash 函數(shù)）一起使用，當(dāng)公鑰算法與摘要算法結(jié)合起來使用時(shí)，便構(gòu)成了一種有效地?cái)?shù)字簽名方案。

簽名證書

通過數(shù)字簽名技術(shù)，確實(shí)可以解決可靠通信的問題。一旦驗(yàn)簽通過，接收者就能確信該消息是期望的發(fā)送者發(fā)送的，而發(fā)送者也不能否認(rèn)曾經(jīng)發(fā)送過該消息。

大家有沒有注意到，前面講的數(shù)字簽名方法，有一個(gè)前提，就是消息的接收者必須事先得到正確的公鑰。如果一開始公鑰就被別人篡改了，那壞人就會(huì)被你當(dāng)成好人，而真正的消息發(fā)送者給你發(fā)的消息會(huì)被你視作無效的。而且，很多時(shí)候根本就不具備事先溝通公鑰的信息通道。

那么如何保證公鑰的安全可信呢？這就要靠數(shù)字證書來解決了。

數(shù)字證書是一個(gè)經(jīng)證書授權(quán)（Certificate Authentication）中心數(shù)字簽名的包含公鑰擁有者信息以及公鑰的文件。數(shù)字證書的格式普遍采用的是 X.509 V3 國(guó)際標(biāo)準(zhǔn)，一個(gè)標(biāo)準(zhǔn)的 X.509 數(shù)字證書通常包含以下內(nèi)容：

證書的發(fā)布機(jī)構(gòu)（Issuer）：該證書是由哪個(gè)機(jī)構(gòu)（CA 中心）頒發(fā)的。

證書的有效期（Validity）：證書的有效期，或者說使用期限。過了該日期，證書就失效了。

證書所有人的公鑰（Public-Key）：該證書所有人想要公布出去的公鑰。

證書所有人的名稱（Subject）：這個(gè)證書是發(fā)給誰的，或者說證書的所有者，一般是某個(gè)人或者某個(gè)公司名稱、機(jī)構(gòu)的名稱、公司網(wǎng)站的網(wǎng)址等。

證書所使用的簽名算法（Signature algorithm）：這個(gè)數(shù)字證書的數(shù)字簽名所使用的加密算法，這樣就可以使用證書發(fā)布機(jī)構(gòu)的證書里面的公鑰，根據(jù)這個(gè)算法對(duì)指紋進(jìn)行解密。

證書發(fā)行者對(duì)證書的數(shù)字簽名（Thumbprint）：數(shù)字證書的hash 值（指紋），用于保證數(shù)字證書的完整性，確保證書沒有被修改過。

數(shù)字證書的原理就是在證書發(fā)布時(shí)，CA 機(jī)構(gòu)會(huì)根據(jù)簽名算法（Signature algorithm）對(duì)整個(gè)證書計(jì)算其 hash 值（指紋）并和證書放在一起，使用者打開證書時(shí)，自己也根據(jù)簽名算法計(jì)算一下證書的 hash 值（指紋），如果和證書中記錄的指紋對(duì)的上，就說明證書沒有被修改過。

可以看出，數(shù)字證書本身也用到了數(shù)字簽名技術(shù)，只不過簽名的內(nèi)容是整個(gè)證書（里面包含了證書所有者的公鑰以及其他一些內(nèi)容）。與普通數(shù)字簽名不同的是，數(shù)字證書的簽名者不是隨隨便便一個(gè)普通機(jī)構(gòu)，而是 CA 機(jī)構(gòu)。

總結(jié)一下，數(shù)字簽名和簽名驗(yàn)證的大體流程如下圖所示：

Android打包流程

整個(gè)Android的打包流程如下圖所示：

編譯打包步驟：

1，打包資源文件，生成R.java文件打包資源的工具是aapt（The Android Asset Packaing Tool）(E:\Documents\Android\sdk\build-tools\25.0.0\aapt.exe)。

在這個(gè)過程中，項(xiàng)目中的AndroidManifest.xml文件和布局文件XML都會(huì)編譯，然后生成相應(yīng)的R.java，另外AndroidManifest.xml會(huì)被aapt編譯成二進(jìn)制。

存放在APP的res目錄下的資源，該類資源在APP打包前大多會(huì)被編譯，變成二進(jìn)制文件，并會(huì)為每個(gè)該類文件賦予一個(gè)resource id。對(duì)于該類資源的訪問，應(yīng)用層代碼則是通過resource id進(jìn)行訪問的。Android應(yīng)用在編譯過程中aapt工具會(huì)對(duì)資源文件進(jìn)行編譯，并生成一個(gè)resource.arsc文件，resource.arsc文件相當(dāng)于一個(gè)文件索引表，記錄了很多跟資源相關(guān)的信息。

2. 處理aidl文件，生成相應(yīng)的Java文件這一過程中使用到的工具是aidl（Android Interface Definition Language），即Android接口描述語言（E:\Documents\Android\sdk\build-tools\25.0.0\aidl.exe）。

aidl工具解析接口定義文件然后生成相應(yīng)的Java代碼接口供程序調(diào)用。如果在項(xiàng)目沒有使用到aidl文件，則可以跳過這一步。

3. 編譯項(xiàng)目源代碼，生成class文件項(xiàng)目中所有的Java代碼，包括R.java和.aidl文件，都會(huì)變Java編譯器（javac）編譯成.class文件，生成的class文件位于工程中的bin/classes目錄下。

4. 轉(zhuǎn)換所有的class文件，生成classes.dex文件dx工具生成可供Android系統(tǒng)Dalvik虛擬機(jī)執(zhí)行的classes.dex文件，該工具位于（E:\Documents\Android\sdk\build-tools\25.0.0\dx.bat）。

任何第三方的libraries和.class文件都會(huì)被轉(zhuǎn)換成.dex文件。dx工具的主要工作是將Java字節(jié)碼轉(zhuǎn)成成Dalvik字節(jié)碼、壓縮常量池、消除冗余信息等。

5. 打包生成APK文件所有沒有編譯的資源，如images、assets目錄下資源（該類文件是一些原始文件，APP打包時(shí)并不會(huì)對(duì)其進(jìn)行編譯，而是直接打包到APP中，對(duì)于這一類資源文件的訪問，應(yīng)用層代碼需要通過文件名對(duì)其進(jìn)行訪問）；編譯過的資源和.dex文件都會(huì)被apkbuilder工具打包到最終的.apk文件中。

打包的工具apkbuilder位于 android-sdk/tools目錄下。apkbuilder為一個(gè)腳本文件，實(shí)際調(diào)用的是（E:\Documents\Android\sdk\tools\lib）文件中的com.android.sdklib.build.ApkbuilderMain類。

6. 對(duì)APK文件進(jìn)行簽名一旦APK文件生成，它必須被簽名才能被安裝在設(shè)備上。

在開發(fā)過程中，主要用到的就是兩種簽名的keystore。一種是用于調(diào)試的debug.keystore，它主要用于調(diào)試，在Eclipse或者Android Studio中直接run以后跑在手機(jī)上的就是使用的debug.keystore。

另一種就是用于發(fā)布正式版本的keystore。

7. 對(duì)簽名后的APK文件進(jìn)行對(duì)齊處理如果你發(fā)布的apk是正式版的話，就必須對(duì)APK進(jìn)行對(duì)齊處理，用到的工具是zipalign（E:\Documents\Android\sdk\build-tools\25.0.0\zipalign.exe）

對(duì)齊的主要過程是將APK包中所有的資源文件距離文件起始偏移為4字節(jié)整數(shù)倍，這樣通過內(nèi)存映射訪問apk文件時(shí)的速度會(huì)更快。對(duì)齊的作用就是減少運(yùn)行時(shí)內(nèi)存的使用。

從上圖可以看到，簽名發(fā)生在打包過程中的倒數(shù)第二步，而且簽名針對(duì)的是已經(jīng)存在的apk包，并不會(huì)影響我們寫的代碼。事實(shí)也確實(shí)是如此，Android的簽名，大致的簽名原理就是對(duì)未簽名的apk里面的所有文件計(jì)算hash，然后保存起來（MANIFEST.MF），然后在對(duì)這些hash計(jì)算hash保存起來(CERT.SF)，然后在計(jì)算hash，然后再通過我們上面生成的keystore里面的私鑰進(jìn)行加密并保存(CERT.RSA)。

Android簽名方案

Android 系統(tǒng)從誕生到現(xiàn)在的1.0版本，一共經(jīng)歷了三代應(yīng)用簽名方案，分別是v1、v2和v3方案。

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

其中，v1 到 v2 是顛覆性的，主要是為了解決 JAR 簽名方案的安全性問題，而到了 v3 方案，其實(shí)結(jié)構(gòu)上并沒有太大的調(diào)整，可以理解為 v2 簽名方案的升級(jí)版。

v1 到 v2 方案的升級(jí)，對(duì)開發(fā)者影響是較大的，就是渠道簽署的問題。v2的簽名也是為了讓不同渠道、市場(chǎng)的安裝包有所區(qū)別，攜帶渠道的標(biāo)識(shí)，也即是我們俗稱的渠道包。好在各大廠都開源了自己的簽渠道方案，例如：Walle（美團(tuán)）、VasDolly（騰訊）都是非常優(yōu)秀的方案。

V1簽名

簽名工具

Android 應(yīng)用的簽名工具有兩種：jarsigner 和 apksigner。它們的簽名算法沒什么區(qū)別，主要是簽名使用的文件不同。它們的區(qū)別如下：

jarsigner：jdk 自帶的簽名工具，可以對(duì) jar 進(jìn)行簽名。使用 keystore 文件進(jìn)行簽名。生成的簽名文件默認(rèn)使用 keystore 的別名命名。

apksigner：Android sdk 提供的專門用于 Android 應(yīng)用的簽名工具。使用 pk8、x509.pem 文件進(jìn)行簽名。其中 pk8 是私鑰文件，x509.pem 是含有公鑰的文件。生成的簽名文件統(tǒng)一使用“CERT”命名。

既然這兩個(gè)工具都是給 APK 簽名的，那么 keystore 文件和 pk8，x509.pem 他們之間是不是有什么聯(lián)系呢？答案是肯定的，他們之間是可以轉(zhuǎn)化的，這里就不再分析它們是如何進(jìn)行轉(zhuǎn)化，網(wǎng)上的例子很多。

還有一個(gè)需要注意的知識(shí)點(diǎn)，如果我們查看一個(gè)keystore 文件的內(nèi)容，會(huì)發(fā)現(xiàn)里面包含有一個(gè) MD5 和 SHA1 摘要，這個(gè)就是 keystore 文件中私鑰的數(shù)據(jù)摘要，這個(gè)信息也是我們?cè)谏暾?qǐng)很多開發(fā)平臺(tái)賬號(hào)時(shí)需要填入的信息。

簽名過程

首先，我們?nèi)我膺x取一個(gè)簽名后的 APK（Sample-release.APK）進(jìn)行解壓，會(huì)得到如下圖所示的文件。

可以發(fā)現(xiàn)，在 META-INF 文件夾下有三個(gè)文件：MANIFEST.MF、CERT.SF、CERT.RSA。它們就是簽名過程中生成的文件，它們的作用如下。

MANIFEST.MF

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

打開MANIFEST.MF文件，文件內(nèi)容如下圖：

CERT.SF

打開CERT.SF文件，文件的內(nèi)容如下：

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

CERT.RSA

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

打開CERT.RSA文件，內(nèi)容如下圖：

這里看到的都是二進(jìn)制文件，因?yàn)?使用RSA 加密了，所以我們需要用 openssl 命令才能查看其內(nèi)容，如下所示。

$ openssl pkcs7 -inform DER -in /<文件存放路徑>/Sample-release_new/original/META-INF/CERT.RSA -text -noout -print_certs

執(zhí)行上面的命令后，得到的內(nèi)容如下圖：

綜上可以看出，一個(gè)完整的簽名過程如下圖：

簽名校驗(yàn)

簽名驗(yàn)證是發(fā)生在 APK 的安裝過程中，一共分為三步：

檢查 APK 中包含的所有文件，對(duì)應(yīng)的摘要值與 MANIFEST.MF 文件中記錄的值一致。使用證書文件（RSA 文件）檢驗(yàn)簽名文件（SF 文件）沒有被修改過。使用簽名文件（SF 文件）檢驗(yàn) MF 文件沒有被修改過。

綜上所述，一個(gè)完整的簽名驗(yàn)證過程如下所示：

V2簽名

APK 簽名方案 v2 是一種全文件簽名方案，該方案能夠發(fā)現(xiàn)對(duì) APK 的受保護(hù)部分進(jìn)行的所有更改，從而有助于加快驗(yàn)證速度并增強(qiáng)完整性保證。通過前面的分析，可以發(fā)現(xiàn) v1 簽名有兩個(gè)地方可以改進(jìn)：

簽名校驗(yàn)速度慢校驗(yàn)過程中需要對(duì)apk中所有文件進(jìn)行摘要計(jì)算，在 APK 資源很多、性能較差的機(jī)器上簽名校驗(yàn)會(huì)花費(fèi)較長(zhǎng)時(shí)間，導(dǎo)致安裝速度慢。

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

為了解決這兩個(gè)問題，在 Android 7.0 版本 中引入了全新的 APK Signature Scheme v2。

V2的改進(jìn)

由于在 v1 僅針對(duì)單個(gè) ZIP 條目進(jìn)行驗(yàn)證，因此，在 APK 簽署后可進(jìn)行許多修改 — 可以移動(dòng)甚至重新壓縮文件。事實(shí)上，編譯過程中要用到的 ZIPalign 工具就是這么做的，它用于根據(jù)正確的字節(jié)限制調(diào)整 ZIP 條目，以改進(jìn)運(yùn)行時(shí)性能。而且我們也可以利用這個(gè)東西，在打包之后修改 META-INF 目錄下面的內(nèi)容，或者修改 ZIP 的注釋來實(shí)現(xiàn)多渠道的打包，在 v1 簽名中都可以校驗(yàn)通過。

v2 簽名將驗(yàn)證歸檔中的所有字節(jié)，而不是單個(gè) ZIP 條目，因此，在簽署后無法再運(yùn)行 ZIPalign（必須在簽名之前執(zhí)行）。正因如此，現(xiàn)在，在編譯過程中，Google 將壓縮、調(diào)整和簽署合并成一步完成。

v2 簽名

v2 簽名會(huì)在原先 APK 塊中增加了一個(gè)新的塊（簽名塊），新的塊存儲(chǔ)了簽名、摘要、簽名算法、證書鏈和額外屬性等信息，這個(gè)塊有特定的格式。最終的簽名APK其實(shí)就有四塊：頭文件區(qū)、V2簽名塊、中央目錄、尾部。下圖是V1簽名和V2簽名的組成。

整個(gè)簽名塊的格式如下：

size of block，以字節(jié)數(shù)（不含此字段）計(jì) (uint64)帶 uint64 長(zhǎng)度前綴的“ID-值”對(duì)序列：size of block，以字節(jié)數(shù)計(jì) - 與第一個(gè)字段相同 (uint64)magic“APK 簽名分塊 42”（16 個(gè)字節(jié)）

在多個(gè)“ID-值”對(duì)中，APK簽名信息的 ID 為 0x7109871a，包含的內(nèi)容如下：帶長(zhǎng)度前綴的 signer：

帶長(zhǎng)度前綴的 signed data，包含digests序列，X.509 certificates 序列，additional attributes序列帶長(zhǎng)度前綴的 signatures（帶長(zhǎng)度前綴）序列帶長(zhǎng)度前綴的 public key（SubjectPublicKeyInfo，ASN.1 DER 形式）value可能會(huì)包含多個(gè) signer，因?yàn)锳ndroid允許多個(gè)簽名。

總結(jié)一下：一個(gè)簽名塊，可以包含多個(gè)ID-VALUE，APK的簽名信息會(huì)存放在 ID 為 0x7109871a的鍵值對(duì)里。他的內(nèi)容可以包含多個(gè)簽名者的簽名信息，每個(gè)簽名信息下包含signed data、signatures、public key，其中，signed data主要存放摘要序列、證書鏈、額外屬性，signatures包含多個(gè)簽名算法計(jì)算出來的簽名值，public key表示簽名者公鑰，用于校驗(yàn)的時(shí)候驗(yàn)證簽名的。

簽名過程

首先，說一下 APK 摘要計(jì)算規(guī)則，對(duì)于每個(gè)摘要算法，計(jì)算結(jié)果如下:

將 APK 中文件 ZIP 條目的內(nèi)容、ZIP 中央目錄、ZIP 中央目錄結(jié)尾按照 1MB 大小分割成一些小塊。計(jì)算每個(gè)小塊的數(shù)據(jù)摘要，數(shù)據(jù)內(nèi)容是 0xa5 + 塊字節(jié)長(zhǎng)度 + 塊內(nèi)容。計(jì)算整體的數(shù)據(jù)摘要，數(shù)據(jù)內(nèi)容是 0x5a + 數(shù)據(jù)塊的數(shù)量 + 每個(gè)數(shù)據(jù)塊的摘要內(nèi)容

總之，就是把 APK 按照 1M 大小分割，分別計(jì)算這些分段的摘要，最后把這些分段的摘要在進(jìn)行計(jì)算得到最終的摘要也就是 APK 的摘要。然后將 APK 的摘要 + 數(shù)字證書 + 其他屬性生成簽名數(shù)據(jù)寫入到 APK Signing Block 區(qū)塊。

簽名校驗(yàn)過程

接下來我們來看一下v2簽名的校驗(yàn)過程，整體大概流程如下圖所示。

其中， v2 簽名機(jī)制是在 Android 7.0 以及以上版本才支持的。因此對(duì)于 Android 7.0 以及以上版本，在安裝過程中，如果發(fā)現(xiàn)有 v2 簽名塊，則必須走 v2 簽名機(jī)制，不能繞過。否則降級(jí)走 v1 簽名機(jī)制。v1 和 v2 簽名機(jī)制是可以同時(shí)存在的，其中對(duì)于 v1 和 v2 版本同時(shí)存在的時(shí)候，v1 版本的 META_INF 的 .SF 文件屬性當(dāng)中有一個(gè) X-Android-APK-Signed 屬性。

X-Android-APK-Signed: 2

之前的渠道包生成方案是通過在 META-INF 目錄下添加空文件，用空文件的名稱來作為渠道的標(biāo)識(shí)。但在新的應(yīng)用簽名方案下 META-INF 已經(jīng)被列入了保護(hù)區(qū)了，向 META-INF 添加空文件的方案會(huì)對(duì)區(qū)塊 1、3、4 都會(huì)有影響。對(duì)于這個(gè)問題，可以參考美團(tuán)多渠道打包總結(jié)。

V3簽名

新版v3簽名在v2的基礎(chǔ)上，仍然采用檢查整個(gè)壓縮包的校驗(yàn)方式。不同的是在簽名部分增可以添加新的證書（Attr塊）。在這個(gè)新塊中，會(huì)記錄我們之前的簽名信息以及新的簽名信息，以密鑰轉(zhuǎn)輪的方案，來做簽名的替換和升級(jí)。這意味著，只要舊簽名證書在手，我們就可以通過它在新的 APK 文件中，更改簽名。

v3 簽名新增的新塊（attr）存儲(chǔ)了所有的簽名信息，由更小的 Level 塊，以鏈表的形式存儲(chǔ)。

其中每個(gè)節(jié)點(diǎn)都包含用于為之前版本的應(yīng)用簽名的簽名證書，最舊的簽名證書對(duì)應(yīng)根節(jié)點(diǎn)，系統(tǒng)會(huì)讓每個(gè)節(jié)點(diǎn)中的證書為列表中下一個(gè)證書簽名，從而為每個(gè)新密鑰提供證據(jù)來證明它應(yīng)該像舊密鑰一樣可信。

簽名校驗(yàn)過程

Android 的簽名方案，無論怎么升級(jí)，都是要確保向下兼容。因此，在引入 v3 方案后，Android 9.0 及更高版本中，可以根據(jù) APK 簽名方案，v3 -> v2 -> v1 依次嘗試驗(yàn)證 APK。而較舊的平臺(tái)會(huì)忽略 v3 簽名并嘗試 v2 簽名，最后才去驗(yàn)證 v1 簽名。整個(gè)驗(yàn)證的過程，如下圖：

需要注意的是，對(duì)于覆蓋安裝的情況，簽名校驗(yàn)只支持升級(jí)，而不支持降級(jí)。也就是說設(shè)備上安裝了一個(gè)使用 v1 簽名的 APK，可以使用 v2 簽名的 APK 進(jìn)行覆蓋安裝，反之則不允許。

“Android簽名機(jī)制是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！

本文標(biāo)題：Android簽名機(jī)制是什么-創(chuàng)新互聯(lián)
文章出自：http://jinyejixie.com/article28/djsicp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供軟件開發(fā)、網(wǎng)站制作、Google、網(wǎng)站策劃、微信小程序、網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)