了解 HTTPS 通信的同學(xué)都知道，在消息通信時(shí)，必須至少解決兩個(gè)問(wèn)題：一是確保消息來(lái)源的真實(shí)性，二是確保消息不會(huì)被第三方篡改。
同理，在安裝 apk 時(shí)，同樣也需要確保 apk 來(lái)源的真實(shí)性，以及 apk 沒(méi)有被第三方篡改。為了解決這一問(wèn)題，Android官方要求開(kāi)發(fā)者對(duì) apk 進(jìn)行簽名，而簽名就是對(duì)apk進(jìn)行加密的過(guò)程。要了解如何實(shí)現(xiàn)簽名，需要了解兩個(gè)基本概念：消息摘要、數(shù)字簽名和數(shù)字證書(shū)。
消息摘要（Message Digest），又稱數(shù)字摘要（Digital Digest）或數(shù)字指紋（Finger Print）。簡(jiǎn)單來(lái)說(shuō)，消息摘要就是在消息數(shù)據(jù)上，執(zhí)行一個(gè)單向的 Hash 函數(shù)，生成一個(gè)固定長(zhǎng)度的Hash值，這個(gè)Hash值即是消息摘要。
上面提到的的加密 Hash 函數(shù)就是消息摘要算法。它有以下特征：
消息摘要看起來(lái)是「隨機(jī)的」。
這些比特看上去是胡亂的雜湊在一起的?？梢杂么罅康妮斎雭?lái)檢驗(yàn)其輸出是否相同，一般，不同的輸入會(huì)有不同的輸出，而且輸出的摘要消息可以通過(guò)隨機(jī)性檢驗(yàn)。但是，一個(gè)摘要并不是真正隨機(jī)的，因?yàn)橛孟嗤乃惴▽?duì)相同的消息求兩次摘要，其結(jié)果必然相同；而若是真正隨機(jī)的，則無(wú)論如何都是無(wú)法重現(xiàn)的。因此消息摘要是「?jìng)坞S機(jī)的」。
消息摘要函數(shù)是單向函數(shù)，即只能進(jìn)行正向的信息摘要，而無(wú)法從摘要中恢復(fù)出任何的消息，甚至根本就找不到任何與原信息相關(guān)的信息。
當(dāng)然，可以采用強(qiáng)力攻擊的方法，即嘗試每一個(gè)可能的信息，計(jì)算其摘要，看看是否與已有的摘要相同，如果這樣做，最終肯定會(huì)恢復(fù)出摘要的消息。但實(shí)際上，要得到的信息可能是無(wú)窮個(gè)消息之一，所以這種強(qiáng)力攻擊幾乎是無(wú)效的。
好的摘要算法，沒(méi)有人能從中找到「碰撞」。或者說(shuō)，無(wú)法找到兩條消息，使它們的摘要相同。雖然「碰撞」是肯定存在的（由于長(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)橄⒄哂羞@種特性，很適合來(lái)驗(yàn)證數(shù)據(jù)的完整性。比如：在網(wǎng)絡(luò)傳輸過(guò)程中下載一個(gè)大文件 BigFile，我們會(huì)同時(shí)從網(wǎng)絡(luò)下載 BigFile 和 BigFile.md5，BigFile.md5 保存 BigFile 的摘要，我們?cè)诒镜厣?BigFile 的消息摘要和 BigFile.md5 比較，如果內(nèi)容相同，則表示下載過(guò)程正確。
數(shù)字簽名的作用就是保證信息傳輸?shù)耐暾浴l(fā)送者的身份認(rèn)證、防止交易中的抵賴發(fā)生。數(shù)字簽名技術(shù)是將摘要信息用發(fā)送者的私鑰加密，與原文一起傳送給接收者。接收者只有用發(fā)送者的公鑰才能解密被加密的摘要信息然后用HASH函數(shù)對(duì)收到的原文產(chǎn)生一個(gè)摘要信息，與解密的摘要信息對(duì)比。如果相同，則說(shuō)明收到的信息是完整的，在傳輸過(guò)程中沒(méi)有被修改，否則說(shuō)明信息被修改過(guò)，因此數(shù)字簽名能夠驗(yàn)證信息的完整性。
如 RSA 作為數(shù)字簽名方案使用時(shí)，它的使用流程如下：這種簽名實(shí)際上就是用信源的私鑰加密消息，加密后的消息即成了簽體；而用對(duì)應(yīng)的公鑰進(jìn)行驗(yàn)證，若公鑰解密后的消息與原來(lái)的消息相同，則消息是完整的，否則消息不完整。
RSA正好和公鑰密碼用于消息保密是相反的過(guò)程。因?yàn)橹挥行旁床艙碛凶约旱厮借€，別人無(wú)法重新加密源消息，所以即使有人截獲且更改了源消息，也無(wú)法重新生成簽體，因?yàn)橹挥杏眯旁吹乃借€才能形成正確地簽體。
同樣信宿只要驗(yàn)證用信源的公鑰解密的消息是否與明文消息相同，就可以知道消息是否被更改過(guò)，而且可以認(rèn)證消息是否是確實(shí)來(lái)自意定的信源，還可以使信源不能否認(rèn)曾經(jīng)發(fā)送的消息。所以 這樣可以完成數(shù)字簽名的功能。
但這種方案過(guò)于單純，它僅可以保證消息的完整性，而無(wú)法確保消息的保密性。而且這種方案要對(duì)所有的消息進(jìn)行加密操作，這在消息的長(zhǎng)度比較大時(shí)，效率是非常低的，主要原因在于公鑰體制的加解密過(guò)程的低效性。所以這種方案一般不可取。
幾乎所有的數(shù)字簽名方案都要和快速高效的摘要算法（Hash 函數(shù)）一起使用，當(dāng)公鑰算法與摘要算法結(jié)合起來(lái)使用時(shí)，便構(gòu)成了一種有效地?cái)?shù)字簽名方案。
通過(guò)數(shù)字簽名技術(shù)，確實(shí)可以解決可靠通信的問(wèn)題。一旦驗(yàn)簽通過(guò)，接收者就能確信該消息是期望的發(fā)送者發(fā)送的，而發(fā)送者也不能否認(rèn)曾經(jīng)發(fā)送過(guò)該消息。
大家有沒(méi)有注意到，前面講的數(shù)字簽名方法，有一個(gè)前提，就是消息的接收者必須事先得到正確的公鑰。如果一開(kāi)始公鑰就被別人篡改了，那壞人就會(huì)被你當(dāng)成好人，而真正的消息發(fā)送者給你發(fā)的消息會(huì)被你視作無(wú)效的。而且，很多時(shí)候根本就不具備事先溝通公鑰的信息通道。
數(shù)字證書(shū)是一個(gè)經(jīng)證書(shū)授權(quán)（Certificate Authentication）中心數(shù)字簽名的包含公鑰擁有者信息以及公鑰的文件。數(shù)字證書(shū)的格式普遍采用的是 X.509 V3 國(guó)際標(biāo)準(zhǔn)，一個(gè)標(biāo)準(zhǔn)的 X.509 數(shù)字證書(shū)通常包含以下內(nèi)容：
證書(shū)的發(fā)布機(jī)構(gòu)（Issuer）：該證書(shū)是由哪個(gè)機(jī)構(gòu)（CA 中心）頒發(fā)的。
證書(shū)的有效期（Validity）：證書(shū)的有效期，或者說(shuō)使用期限。過(guò)了該日期，證書(shū)就失效了。
證書(shū)所有人的公鑰（Public-Key）：該證書(shū)所有人想要公布出去的公鑰。
證書(shū)所有人的名稱（Subject）：這個(gè)證書(shū)是發(fā)給誰(shuí)的，或者說(shuō)證書(shū)的所有者，一般是某個(gè)人或者某個(gè)公司名稱、機(jī)構(gòu)的名稱、公司網(wǎng)站的網(wǎng)址等。
證書(shū)所使用的簽名算法（Signature algorithm）：這個(gè)數(shù)字證書(shū)的數(shù)字簽名所使用的加密算法，這樣就可以使用證書(shū)發(fā)布機(jī)構(gòu)的證書(shū)里面的公鑰，根據(jù)這個(gè)算法對(duì)指紋進(jìn)行解密。
證書(shū)發(fā)行者對(duì)證書(shū)的數(shù)字簽名（Thumbprint）：數(shù)字證書(shū)的hash 值（指紋），用于保證數(shù)字證書(shū)的完整性，確保證書(shū)沒(méi)有被修改過(guò)。
數(shù)字證書(shū)的原理就是在證書(shū)發(fā)布時(shí)，CA 機(jī)構(gòu)會(huì)根據(jù)簽名算法（Signature algorithm）對(duì)整個(gè)證書(shū)計(jì)算其 hash 值（指紋）并和證書(shū)放在一起，使用者打開(kāi)證書(shū)時(shí)，自己也根據(jù)簽名算法計(jì)算一下證書(shū)的 hash 值（指紋），如果和證書(shū)中記錄的指紋對(duì)的上，就說(shuō)明證書(shū)沒(méi)有被修改過(guò)。
可以看出，數(shù)字證書(shū)本身也用到了數(shù)字簽名技術(shù)，只不過(guò)簽名的內(nèi)容是整個(gè)證書(shū)（里面包含了證書(shū)所有者的公鑰以及其他一些內(nèi)容）。與普通數(shù)字簽名不同的是，數(shù)字證書(shū)的簽名者不是隨隨便便一個(gè)普通機(jī)構(gòu)，而是 CA 機(jī)構(gòu)。
總結(jié)一下，數(shù)字簽名和簽名驗(yàn)證的大體流程如下圖所示：
編譯打包步驟：
打包資源的工具是aapt（The Android Asset Packaing Tool）(E:\Documents\Android\sdk\build-tools\25.0.0\aapt.exe)。
在這個(gè)過(guò)程中，項(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ì)于該類資源的訪問(wèn)，應(yīng)用層代碼則是通過(guò)resource id進(jìn)行訪問(wèn)的。Android應(yīng)用在編譯過(guò)程中aapt工具會(huì)對(duì)資源文件進(jìn)行編譯，并生成一個(gè)resource.arsc文件，resource.arsc文件相當(dāng)于一個(gè)文件索引表，記錄了很多跟資源相關(guān)的信息。
這一過(guò)程中使用到的工具是aidl（Android Interface Definition Language），即Android接口描述語(yǔ)言（E:\Documents\Android\sdk\build-tools\25.0.0\aidl.exe）。
aidl工具解析接口定義文件然后生成相應(yīng)的Java代碼接口供程序調(diào)用。如果在項(xiàng)目沒(méi)有使用到aidl文件，則可以跳過(guò)這一步。
項(xiàng)目中所有的Java代碼，包括R.java和.aidl文件，都會(huì)變Java編譯器（javac）編譯成.class文件，生成的class文件位于工程中的bin/classes目錄下。
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é)碼、壓縮常量池、消除冗余信息等。
所有沒(méi)有編譯的資源，如images、assets目錄下資源（該類文件是一些原始文件，APP打包時(shí)并不會(huì)對(duì)其進(jìn)行編譯，而是直接打包到APP中，對(duì)于這一類資源文件的訪問(wèn)，應(yīng)用層代碼需要通過(guò)文件名對(duì)其進(jìn)行訪問(wèn)）；編譯過(guò)的資源和.dex文件都會(huì)被apkbuilder工具打包到最終的.apk文件中。
打包的工具apkbuilder位于 android-sdk/tools目錄下。apkbuilder為一個(gè)腳本文件，實(shí)際調(diào)用的是（E:\Documents\Android\sdk\tools\lib）文件中的com.android.sdklib.build.ApkbuilderMain類。
一旦APK文件生成，它必須被簽名才能被安裝在設(shè)備上。
在開(kāi)發(fā)過(guò)程中，主要用到的就是兩種簽名的keystore。一種是用于調(diào)試的debug.keystore，它主要用于調(diào)試，在Eclipse或者Android Studio中直接run以后跑在手機(jī)上的就是使用的debug.keystore。
另一種就是用于發(fā)布正式版本的keystore。
如果你發(fā)布的apk是正式版的話，就必須對(duì)APK進(jìn)行對(duì)齊處理，用到的工具是zipalign（E:\Documents\Android\sdk\build-tools\25.0.0\zipalign.exe）
對(duì)齊的主要過(guò)程是將APK包中所有的資源文件距離文件起始偏移為4字節(jié)整數(shù)倍，這樣通過(guò)內(nèi)存映射訪問(wèn)apk文件時(shí)的速度會(huì)更快。對(duì)齊的作用就是減少運(yùn)行時(shí)內(nèi)存的使用。
從上圖可以看到，簽名發(fā)生在打包過(guò)程中的倒數(shù)第二步，而且簽名針對(duì)的是已經(jīng)存在的apk包，并不會(huì)影響我們寫(xiě)的代碼。事實(shí)也確實(shí)是如此，Android的簽名，大致的簽名原理就是對(duì)未簽名的apk里面的所有文件計(jì)算hash，然后保存起來(lái)（MANIFEST.MF），然后在對(duì)這些hash計(jì)算hash保存起來(lái)(CERT.SF)，然后在計(jì)算hash，然后再通過(guò)我們上面生成的keystore里面的私鑰進(jìn)行加密并保存(CERT.RSA)。
Android 應(yīng)用的簽名工具有兩種：jarsigner 和 apksigner。它們的簽名算法沒(méi)什么區(qū)別，主要是簽名使用的文件不同。它們的區(qū)別如下：
jarsigner：jdk 自帶的簽名工具，可以對(duì) jar 進(jìn)行簽名。使用 keystore 文件進(jìn)行簽名。生成的簽名文件默認(rèn)使用 keystore 的別名命名。
apksigner：Android sdk 提供的專門(mén)用于 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)很多開(kāi)發(fā)平臺(tái)賬號(hào)時(shí)需要填入的信息。
檢查 APK 中包含的所有文件，對(duì)應(yīng)的摘要值與 MANIFEST.MF 文件中記錄的值一致。
使用證書(shū)文件（RSA 文件）檢驗(yàn)簽名文件（SF 文件）沒(méi)有被修改過(guò)。
使用簽名文件（SF 文件）檢驗(yàn) MF 文件沒(méi)有被修改過(guò)。
APK 簽名方案 v2 是一種全文件簽名方案，該方案能夠發(fā)現(xiàn)對(duì) APK 的受保護(hù)部分進(jìn)行的所有更改，從而有助于加快驗(yàn)證速度并增強(qiáng)完整性保證。通過(guò)前面的分析，可以發(fā)現(xiàn) v1 簽名有兩個(gè)地方可以改進(jìn)：
簽名校驗(yàn)速度慢
校驗(yàn)過(guò)程中需要對(duì)apk中所有文件進(jìn)行摘要計(jì)算，在 APK 資源很多、性能較差的機(jī)器上簽名校驗(yàn)會(huì)花費(fèi)較長(zhǎng)時(shí)間，導(dǎo)致安裝速度慢。
完整性保障不夠
META-INF 目錄用來(lái)存放簽名，自然此目錄本身是不計(jì)入簽名校驗(yàn)過(guò)程的，可以隨意在這個(gè)目錄中添加文件，比如一些快速批量打包方案就選擇在這個(gè)目錄中添加渠道文件。
為了解決這兩個(gè)問(wèn)題，在 Android 7.0 版本 中引入了全新的 APK Signature Scheme v2。
由于在 v1 僅針對(duì)單個(gè) ZIP 條目進(jìn)行驗(yàn)證，因此，在 APK 簽署后可進(jìn)行許多修改 — 可以移動(dòng)甚至重新壓縮文件。事實(shí)上，編譯過(guò)程中要用到的 ZIPalign 工具就是這么做的，它用于根據(jù)正確的字節(jié)限制調(diào)整 ZIP 條目，以改進(jìn)運(yùn)行時(shí)性能。而且我們也可以利用這個(gè)東西，在打包之后修改 META-INF 目錄下面的內(nèi)容，或者修改 ZIP 的注釋來(lái)實(shí)現(xiàn)多渠道的打包，在 v1 簽名中都可以校驗(yàn)通過(guò)。
v2 簽名將驗(yàn)證歸檔中的所有字節(jié)，而不是單個(gè) ZIP 條目，因此，在簽署后無(wú)法再運(yùn)行 ZIPalign（必須在簽名之前執(zhí)行）。正因如此，現(xiàn)在，在編譯過(guò)程中，Google 將壓縮、調(diào)整和簽署合并成一步完成。
v2 簽名會(huì)在原先 APK 塊中增加了一個(gè)新的塊（簽名塊），新的塊存儲(chǔ)了簽名、摘要、簽名算法、證書(shū)鏈和額外屬性等信息，這個(gè)塊有特定的格式。最終的簽名APK其實(shí)就有四塊：頭文件區(qū)、V2簽名塊、中央目錄、尾部。下圖是V1簽名和V2簽名的組成。
X-Android-APK-Signed: 2
Android 的簽名方案，無(wú)論怎么升級(jí)，都是要確保向下兼容。因此，在引入 v3 方案后，Android 9.0 及更高版本中，可以根據(jù) APK 簽名方案，v3 -> v2 -> v1 依次嘗試驗(yàn)證 APK。而較舊的平臺(tái)會(huì)忽略 v3 簽名并嘗試 v2 簽名，最后才去驗(yàn)證 v1 簽名。
整個(gè)驗(yàn)證的過(guò)程，如下圖：
需要注意的是，對(duì)于覆蓋安裝的情況，簽名校驗(yàn)只支持升級(jí)，而不支持降級(jí)。也就是說(shuō)設(shè)備上安裝了一個(gè)使用 v1 簽名的 APK，可以使用 v2 簽名的 APK 進(jìn)行覆蓋安裝，反之則不允許。關(guān)于V3簽名的更多知識(shí)，可以參考下面的文章：Android v3簽名新特性
聯(lián)系客服
