網(wǎng)上有很多關(guān)于pos機(jī)出現(xiàn)簽名摘要錯(cuò)誤,梳理3個(gè)知識(shí)點(diǎn)讓你了解Android簽名機(jī)制的知識(shí)，也有很多人為大家解答關(guān)于pos機(jī)出現(xiàn)簽名摘要錯(cuò)誤的問(wèn)題，今天pos機(jī)之家(m.afbey.com)為大家整理了關(guān)于這方面的知識(shí)，讓我們一起來(lái)看下吧!
本文目錄一覽：
pos機(jī)出現(xiàn)簽名摘要錯(cuò)誤
一、準(zhǔn)備知識(shí)在介紹簽名機(jī)制前，需要首先了解一下消息摘要、簽名文件、數(shù)字證書(shū)的知識(shí)。
1、消息摘要 - Message Digest
消息摘要（Message Digest），又稱(chēng)數(shù)字摘要（Digital Digest）或數(shù)字指紋（Finger Print）。簡(jiǎn)單來(lái)說(shuō)，消息摘要就是在消息數(shù)據(jù)上，執(zhí)行一個(gè)單向的Hash函數(shù)，生成一個(gè)固定長(zhǎng)度的Hash值，這個(gè)Hash值即是消息摘要。關(guān)于這個(gè)Hash函數(shù)，我們來(lái)看看維基百科上的定義：
https://en.wikipedia.org/wiki/Cryptographic_hash_function
A cryptographic hash function is a special class of hash function that has certain properties which make it suitable for use in cryptography. It is a mathematical algorithm that maps data of arbitrary size to a bit string of a fixed size (a hash function) which is designed to also be a one-way function, that is, a function which is infeasible to invert. The only way to recreate the input data from an ideal cryptographic hash function\'s output is to attempt a brute-force search of possible inputs to see if they produce a match, or use a rainbow table of matched hashes. Bruce Schneier has called one-way hash functions "the workhorses of modern cryptography".[1] The input data is often called the message, and the output (the hash value or hash) is often called the message digest or simply the digest.
The ideal cryptographic hash function has five main properties:
it is deterministic so the same message always results in the same hash
it is quick to compute the hash value for any given message
it is infeasible to generate a message from its hash value except by trying all possible messages
a small change to a message should change the hash value so extensively that the new hash value appears uncorrelated with the old hash value
it is infeasible to find two different messages with the same hash value
Cryptographic hash functions have many information-security applications, notably in digital signatures, message authentication codes (MACs), and other forms of authentication. They can also be used as ordinary hash functions, to index data in hash tables, for fingerprinting, to detect duplicate data or uniquely identify files, and as checksums to detect accidental data corruption. Indeed, in information-security contexts, cryptographic hash values are sometimes called (digital) fingerprints, checksums, or just hash values, even though all these terms stand for more general functions with rather different properties and purposes.
A cryptographic hash function (specifically SHA-1) at work. A small change in the input (in the word "over") drastically changes the output (digest). This is the so-called avalanche effect.
上面提到的的加密Hash函數(shù)就是消息摘要算法。它有以下特征：
無(wú)論輸入的消息有多長(zhǎng)，計(jì)算出來(lái)的消息摘要的長(zhǎng)度總是固定的。例如應(yīng)用MD5算法摘要的消息有128個(gè)比特位，用SHA-1算法摘要的消息最終有160比特位的輸出，SHA-1的變體可以產(chǎn)生192比特位和256比特位的消息摘要。一般認(rèn)為，摘要的最終輸出越長(zhǎng)，該摘要算法就越安全。
消息摘要看起來(lái)是“隨機(jī)的”。這些比特看上去是胡亂的雜湊在一起的?？梢杂么罅康妮斎雭?lái)檢驗(yàn)其輸出是否相同，一般，不同的輸入會(huì)有不同的輸出，而且輸出的摘要消息可以通過(guò)隨機(jī)性檢驗(yàn)。但是，一個(gè)摘要并不是真正隨機(jī)的，因?yàn)橛孟嗤乃惴▽?duì)相同的消息求兩次摘要，其結(jié)果必然相同；而若是真正隨機(jī)的，則無(wú)論如何都是無(wú)法重現(xiàn)的。因此消息摘要是“偽隨機(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)有人能從中找到“碰撞”，雖然“碰撞”是肯定存在的（由于長(zhǎng)明文生成短摘要的Hash必然會(huì)產(chǎn)生碰撞）。即對(duì)于給定的一個(gè)摘要，不可能找到一條信息使其摘要正好是給定的。或者說(shuō)，無(wú)法找到兩條消息，使它們的摘要相同。
正是由于以上特點(diǎn)，消息摘要算法被廣泛應(yīng)用在“數(shù)字簽名”領(lǐng)域，作為對(duì)明文的摘要算法。著名的消息摘要算法有RSA公司的MD5算法和SHA-1算法及其大量的變體。
2、數(shù)字簽名 - Signature
數(shù)字簽名方案是一種以電子形式存儲(chǔ)消息簽名的方法。一個(gè)完整的數(shù)字簽名方案應(yīng)該由兩部分組成：簽名算法和驗(yàn)證算法。在講數(shù)字簽名之前，我們先簡(jiǎn)單介紹幾個(gè)相關(guān)知識(shí)點(diǎn)：“公鑰密碼體制”、“對(duì)稱(chēng)加密算法”、“非對(duì)稱(chēng)加密算法”。
公鑰密碼體制(public-key cryptography)
公鑰密碼體制分為三個(gè)部分，公鑰、私鑰、加密解密算法，它的加密解密過(guò)程如下：
加密：通過(guò)加密算法和公鑰對(duì)內(nèi)容(或者說(shuō)明文)進(jìn)行加密，得到密文。加密過(guò)程需要用到公鑰。
解密：通過(guò)解密算法和私鑰對(duì)密文進(jìn)行解密，得到明文。解密過(guò)程需要用到解密算法和私鑰。注意，由公鑰加密的內(nèi)容，只能由私鑰進(jìn)行解密，也就是說(shuō)，由公鑰加密的內(nèi)容，如果不知道私鑰，是無(wú)法解密的。
公 鑰密碼體制的公鑰和算法都是公開(kāi)的(這是為什么叫公鑰密碼體制的原因)，私鑰是保密的。大家都以使用公鑰進(jìn)行加密，但是只有私鑰的持有者才能解密。在實(shí)際 的使用中，有需要的人會(huì)生成一對(duì)公鑰和私鑰，把公鑰發(fā)布出去給別人使用，自己保留私鑰。目前使用最廣泛的公鑰密碼體制是RSA密碼體制。
對(duì)稱(chēng)加密算法(symmetric key algorithms)
在對(duì)稱(chēng)加密算法中，加密和解密都是使用的同一個(gè)密鑰。因此對(duì)稱(chēng)加密算法要保證安全性的話，密鑰要做好保密，只能讓使用的人知道，不能對(duì)外公開(kāi)。
非對(duì)稱(chēng)加密算法(asymmetric key algorithms)
在非對(duì)稱(chēng)加密算法中，加密使用的密鑰和解密使用的密鑰是不相同的。前面所說(shuō)的公鑰密碼體制就是一種非對(duì)稱(chēng)加密算法，他的公鑰和是私鑰是不能相同的，也就是說(shuō)加密使用的密鑰和解密使用的密鑰不同，因此它是一個(gè)非對(duì)稱(chēng)加密算法。
RSA簡(jiǎn)介
RSA密碼體制是一種公鑰密碼體制，公鑰公開(kāi)，私鑰保密，它的加密解密算法是公開(kāi)的。 由公鑰加密的內(nèi)容可以并且只能由私鑰進(jìn)行解密，而由私鑰加密的內(nèi)容可以并且只能由公鑰進(jìn)行解密。也就是說(shuō)，RSA的這一對(duì)公鑰、私鑰都可以用來(lái)加密和解密，并且一方加密的內(nèi)容可以由并且只能由對(duì)方進(jìn)行解密。
加密：公鑰加密，私鑰解密的過(guò)程，稱(chēng)為“加密”。因?yàn)楣€是公開(kāi)的，任何公鑰持有者都可以將想要發(fā)送給私鑰持有者的信息進(jìn)行加密后發(fā)送，而這個(gè)信息只有私鑰持有者才能解密。
簽名： 私鑰加密，公鑰解密的過(guò)程，稱(chēng)為“簽名”。它和加密有什么區(qū)別呢？因?yàn)楣€是公開(kāi)的，所以任何持有公鑰的人都能解密私鑰加密過(guò)的密文，所以這個(gè)過(guò)程并不能 保證消息的安全性，但是它卻能保證消息來(lái)源的準(zhǔn)確性和不可否認(rèn)性，也就是說(shuō)，如果使用公鑰能正常解密某一個(gè)密文，那么就能證明這段密文一定是由私鑰持有者 發(fā)布的，而不是其他第三方發(fā)布的，并且私鑰持有者不能否認(rèn)他曾經(jīng)發(fā)布過(guò)該消息。故此將該過(guò)程稱(chēng)為“簽名”。
數(shù)字簽名
事實(shí)上，任何一個(gè)公鑰密碼體制都可以單獨(dú)地作為一種數(shù)字簽名方案使用。如RSA作為數(shù)字簽名方案使用時(shí)，可以定義如下：
這種簽名實(shí)際上就是用信源的私鑰加密消息，加密后的消息即成了簽體；而用對(duì)應(yīng)的公鑰進(jìn) 行驗(yàn)證，若公鑰解密后的消息與原來(lái)的消息相同，則消息是完整的，否則消息不完整。它正好和公鑰密碼用于消息保密是相反的過(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ù)字簽名方案。
這個(gè)過(guò)程是：
用摘要算法對(duì)消息進(jìn)行摘要。
再把摘要值用信源的私鑰加密。
通過(guò)以上兩步得到的消息就是所謂的原始信息的數(shù)字簽名，發(fā)送者需要將原始信息和數(shù)字簽名一同發(fā)送給接收者。而接收者在接收到原始信息和數(shù)字簽名后，通過(guò)以下3步驗(yàn)證消息的真?zhèn)危?/p>
先把接收到的原始消息用同樣的摘要算法摘要，形成“準(zhǔn)簽體”。
對(duì)附加上的那段數(shù)字簽名，使用預(yù)先得到的公鑰解密。
比較前兩步所得到的兩段消息是否一致。如果一致，則表明消息確實(shí)是期望的發(fā)送者發(fā)的，且內(nèi)容沒(méi)有被篡改過(guò)；相反，如果不一致，則表明傳送的過(guò)程中一定出了問(wèn)題，消息不可信。
這種方法使公鑰加密只對(duì)消息摘要進(jìn)行操作，因?yàn)橐环N摘要算法的摘要消息長(zhǎng)度是固定的，而且都比較“短”（相對(duì)于消息而言），正好符合公鑰加密的要求。這樣效率得到了提高，而其安全性也并未因?yàn)槭褂谜惴ǘ鴾p弱。
綜上所述，數(shù)字簽名是非對(duì)稱(chēng)加密技術(shù) + 消息摘要技術(shù)的結(jié)合。
3、數(shù)字證書(shū) - Certificate
通過(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ū)來(lái)解決了。
數(shù)字證書(shū)是一個(gè)經(jīng)證書(shū)授權(quán)（Certificate Authentication）中心數(shù)字簽名的包含公鑰擁有者信息以及公鑰的文件。數(shù)字證書(shū)的格式普遍采用的是X.509V3國(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ū)所有人的名稱(chēng)（Subject）
- 這個(gè)證書(shū)是發(fā)給誰(shuí)的，或者說(shuō)證書(shū)的所有者，一般是某個(gè)人或者某個(gè)公司名稱(chēng)、機(jī)構(gòu)的名稱(chēng)、公司網(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ū)的指紋，用于保證數(shù)字證書(shū)的完整性，確保證書(shū)沒(méi)有被修改過(guò)。其原理就是在發(fā)布證書(shū)時(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)。這就好像 你的大學(xué)畢業(yè)證書(shū)上簽名的一般都是德高望重的校長(zhǎng)一樣。一般來(lái)說(shuō)，這些CA機(jī)構(gòu)的根證書(shū)已經(jīng)在設(shè)備出廠前預(yù)先安裝到了你的設(shè)備上了。所以，數(shù)字證書(shū)可以保 證證書(shū)里的公鑰確實(shí)是這個(gè)證書(shū)所有者的，或者證書(shū)可以用來(lái)確認(rèn)對(duì)方的身份?？梢?jiàn)，數(shù)字證書(shū)主要是用來(lái)解決公鑰的安全發(fā)放問(wèn)題。
綜上所述，總結(jié)一下，數(shù)字簽名和簽名驗(yàn)證的大體流程如下圖所示：
二、Android簽名機(jī)制1、簽名工具
Android應(yīng)用的簽名工具有兩種：jarsigner和signapk。它們的簽名算法沒(méi)什么區(qū)別，主要是簽名使用的文件不同。
jarsigner：jdk自帶的簽名工具，可以對(duì)jar進(jìn)行簽名。使用keystore文件進(jìn)行簽名。生成的簽名文件默認(rèn)使用keystore的別名命名。
signapk：Android sdk提供的專(zhuān)門(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í)需要填入的信息。
2、簽名過(guò)程
首先我們?nèi)我膺x取一個(gè)簽名后的APK（SMSSDKSample-release.apk）解壓：
在META-INF文件夾下有三個(gè)文件：MANIFEST.MF、CERT.SF、CERT.RSA。它們就是簽名過(guò)程中生成的文件，姑且叫他們“簽名三兄弟”吧，把它們搞清楚了，你就精通簽名了。
（1）MANIFEST.MF
該 文件中保存的內(nèi)容其實(shí)就是逐一遍歷apk中的所有條目，如果是目錄就跳過(guò)，如果是一個(gè)文件，就用SHA1（或者SHA256）消息摘要算法提取出該文件的 摘要然后進(jìn)行BASE64編碼后，作為“SHA1-Digest”屬性的值寫(xiě)入到MANIFEST.MF文件中的一個(gè)塊中。該塊有一個(gè)“Name”屬性， 其值就是該文件在apk包中的路徑。
（2）CERT.SF
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編碼
對(duì)于SHA1-Digest值的驗(yàn)證可以手動(dòng)進(jìn)行，將MANIFEST.MF中任意一個(gè)塊的內(nèi)容復(fù)制并保存在一個(gè)新的文檔中，注意文末需要加兩個(gè)換行（這是由signapk的源碼決定的）
保存文件，然后對(duì)該文件計(jì)算其SHA1值后使用Base64編碼：
得到的值就是CERT.SF中相應(yīng)條目的SHA1-Digest的值：
（3）CERT.RSA
這里會(huì)把之前生成的 CERT.SF文件，用私鑰計(jì)算出簽名, 然后將簽名以及包含公鑰信息的數(shù)字證書(shū)一同寫(xiě)入 CERT.RSA 中保存。這里要注意的是，Android APK中的CERT.RSA證書(shū)是自簽名的，并不需要這個(gè)證書(shū)是第三方權(quán)威機(jī)構(gòu)發(fā)布或者認(rèn)證的，用戶(hù)可以在本地機(jī)器自行生成這個(gè)自簽名證書(shū)。Android 目前不對(duì)應(yīng)用證書(shū)進(jìn)行 CA 認(rèn)證。
什么是自簽名證書(shū)
所謂自簽名證書(shū)是指自己給自己頒發(fā)的證書(shū)，即公鑰證書(shū)中Issuer（發(fā)布者）和 Subject（所有者）是相同的。當(dāng)然，APK也可以采用由CA頒發(fā)私鑰證書(shū)進(jìn)行簽名。采用非自簽名時(shí)，最終APK的公鑰證書(shū)中就會(huì)包含證書(shū)鏈，并且會(huì) 存在多余一個(gè)證書(shū)，證書(shū)間通過(guò)Issuer與Subject進(jìn)行關(guān)聯(lián)，Issuer負(fù)責(zé)對(duì)Subject進(jìn)行認(rèn)證。當(dāng)安裝APK時(shí)，系統(tǒng)只會(huì)用位于證書(shū)鏈 中最底層的證書(shū)對(duì)APK進(jìn)行校驗(yàn)，但并不會(huì)驗(yàn)證證書(shū)鏈的有效性。在Https通信中使用自簽名證書(shū)時(shí)瀏覽器的顯示效果：
這里我們看到的都是二進(jìn)制文件，因?yàn)镽SA文件加密了，所以我們需要用openssl命令才能查看其內(nèi)容：
openssl pkcs7 -inform DER -in /Users/jackie/Downloads/apk簽名機(jī)制/SMSSDKSample-release_new/original/META-INF/DEMOKEY_.RSA -text -noout -print_certs
關(guān)于這些信息，可以看下面這張圖：
綜上所述，一個(gè)完整的簽名過(guò)程如下所示：
3、簽名驗(yàn)證過(guò)程
簽名驗(yàn)證是發(fā)生在apk的安裝過(guò)程中，一共分為三步：
（1）檢查apk中包含的所有文件，對(duì)應(yīng)的摘要值與MANIFEST.MF文件中記錄的值一致。
（2）使用證書(shū)文件（RSA文件）檢驗(yàn)簽名文件（SF文件）沒(méi)有被修改過(guò)。
（3）使用簽名文件（SF文件）檢驗(yàn)MF文件沒(méi)有被修改過(guò)。
綜上所述，一個(gè)完整的簽名驗(yàn)證過(guò)程如下所示：
為什么使用這樣的簽名流程呢？
我們假設(shè)一下，首先，如果你改變了apk包中的任何文件，那么在apk安裝校驗(yàn)時(shí)，改變后的文件摘要信息與MANIFEST.MF的檢驗(yàn)信息不同，于是驗(yàn)證失敗，程序就不能成功安裝。
其次，如果你對(duì)更改過(guò)的文件相應(yīng)的算出新的摘要值，然后更改MANIFEST.MF文件里面對(duì)應(yīng)的屬性值，那么必定與CERT.SF文件中算出的摘要值不一樣，照樣驗(yàn)證失敗。
最后，如果你還不死心，繼續(xù)計(jì)算MANIFEST.MF的摘要值，相應(yīng)的更改CERT.SF里面的值，那么數(shù)字簽名值必定與CERT.RSA文件中記錄的不一樣，還是失敗。
那么能不能繼續(xù)偽造數(shù)字簽名呢？不可能，因?yàn)闆](méi)有數(shù)字證書(shū)對(duì)應(yīng)的私鑰。
三、APK Signature Scheme v2在 Android 7.0 Nougat 中引入了全新的 APK Signature Scheme v2。
APK 簽名方案 v2 是一種全文件簽名方案，該方案能夠發(fā)現(xiàn)對(duì) APK 的受保護(hù)部分進(jìn)行的所有更改，從而有助于加快驗(yàn)證速度并增強(qiáng)完整性保證。
1、原因
為什么谷歌要做這個(gè)事情呢？第一點(diǎn)毋庸置疑，肯定是處于安全性的考慮，之前的校驗(yàn)方式開(kāi)發(fā)者可以在打包之后對(duì)apk做很多處理，第二為了性能考慮，安裝校驗(yàn)的時(shí)候不需要再解壓縮校驗(yàn)，從而提升安裝速度。
2、v2帶來(lái)了什么變化
由 于在 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)整和簽署合并成一步完成。
3、新的簽名方案就是一種擴(kuò)展的Zip格式
使用 APK 簽名方案 v2 進(jìn)行簽名時(shí)，會(huì)在 APK 文件中插入一個(gè) APK 簽名分塊，該分塊位于“ZIP 中央目錄”部分之前并緊鄰該部分。在“APK 簽名分塊”內(nèi)，v2 簽名和簽名者身份信息會(huì)存儲(chǔ)在 APK 簽名方案 v2 分塊中。
4、受完整性保護(hù)的內(nèi)容
為了保護(hù)APK內(nèi)容，整個(gè)APK（zip文件格式）被分為以下4個(gè)區(qū)塊：
ZIP 條目的內(nèi)容（從偏移量 0 處開(kāi)始一直到“APK 簽名分塊”的起始位置）
APK 簽名分塊
ZIP 中央目錄
ZIP 中央目錄結(jié)尾
APK 簽名方案 v2 負(fù)責(zé)保護(hù)第 1、3、4 部分的完整性，以及第 2 部分包含的“APK 簽名方案 v2 分塊”中的 signed data 分塊的完整性。
第 1、3 和 4 部分的完整性通過(guò)其內(nèi)容的一個(gè)或多個(gè)摘要來(lái)保護(hù)，這些摘要存儲(chǔ)在 signed data 分塊中，而這些分塊則通過(guò)一個(gè)或多個(gè)簽名來(lái)保護(hù)。
5、新舊簽名方案的兼容
新的簽名格式向后兼容，因此，使用這種新格式簽名的 APK 可在更低版本的 Android 設(shè)備上進(jìn)行安裝（會(huì)直接忽略添加到 APK 的額外數(shù)據(jù)），但前提是這些 APK 還帶有 v1 簽名。
驗(yàn) 證程序會(huì)對(duì)照存儲(chǔ)在“APK 簽名分塊”中的 v2 簽名對(duì) APK 的全文件哈希進(jìn)行驗(yàn)證。該哈希涵蓋除“APK 簽名分塊”（其中包含 v2 簽名）之外的所有內(nèi)容。在“APK 簽名分塊”以外對(duì) APK 進(jìn)行的任何修改都會(huì)使 APK 的 v2 簽名作廢。v2 簽名被刪除的 APK 也會(huì)被拒絕，因?yàn)?v1 簽名指明相應(yīng) APK 帶有 v2 簽名，所以 Android Nougat 及更高版本會(huì)拒絕使用 v1 簽名驗(yàn)證 APK。這就是所謂的“防回滾保護(hù)”。
防回滾保護(hù)
攻擊者可能會(huì)試圖在支持對(duì)帶 v2 簽名的 APK 進(jìn)行驗(yàn)證的 Android 平臺(tái)上將帶 v2 簽名的 APK 作為帶 v1 簽名的 APK 進(jìn)行驗(yàn)證。為了防范此類(lèi)攻擊，帶 v2 簽名的 APK 如果還帶 v1 簽名，其 META-INF/*.SF 文件的主要部分中必須包含 X-Android-APK-Signed 屬性。該屬性的值是一組以英文逗號(hào)分隔的 APK 簽名方案 ID（v2 方案的 ID 為 2）。在驗(yàn)證 v1 簽名時(shí)，對(duì)于此組中驗(yàn)證程序首選的 APK 簽名方案（例如，v2 方案），如果 APK 沒(méi)有相應(yīng)的簽名，APK 驗(yàn)證程序必須要拒絕這些 APK。此項(xiàng)保護(hù)依賴(lài)于內(nèi)容 META-INF/*.SF 文件受 v1 簽名保護(hù)這一事實(shí)。
6、新簽名方案v2對(duì)現(xiàn)存的渠道包生成工具的影響
之前的渠道包生成方案是通過(guò)在META-INF目錄下添加空文件，用空文件的名稱(chēng)來(lái)作為渠道的唯一標(biāo)識(shí)。但在新的應(yīng)用簽名方案下META-INF已經(jīng)被列入了保護(hù)區(qū)了，向META-INF添加空文件的方案會(huì)對(duì)區(qū)塊1、3、4都會(huì)有影響。
另外一種比較流行的渠道包快速生成方案（修改Zip的注釋?zhuān)┮惨驗(yàn)樯鲜鲈?，無(wú)法在新的應(yīng)用簽名方案下進(jìn)行正常工作。
如果新簽名方案v2后續(xù)改成強(qiáng)制要求，那現(xiàn)有的生成渠道包的方式就會(huì)無(wú)法工作，難道要退回到解放前嗎？
從 上面的描述可以看到，區(qū)塊1、3、4都是被保護(hù)的，任何針對(duì)這3個(gè)區(qū)塊的修改都會(huì)被新簽名方案v2檢測(cè)到，但區(qū)塊2（APK Signing Block）是不受簽名校驗(yàn)規(guī)則保護(hù)的。美團(tuán)的新一代打渠道包工具Walle就是往區(qū)塊2寫(xiě)入一個(gè)自定義的ID-value，在App運(yùn)行階段，可以通過(guò) ZIP的EOCD（End of central directory）、Central directory等結(jié)構(gòu)中的信息（涉及ZIP格式的相關(guān)知識(shí)，這里不做展開(kāi)描述）找到我們自己添加的ID-value，從而實(shí)現(xiàn)獲取渠道信息的功能，來(lái) 應(yīng)對(duì)新簽名方案v2的。
四、知識(shí)點(diǎn)梳理1、公鑰密碼體制：
公鑰密碼體制的公鑰和算法都是公開(kāi)的，私鑰是保密的。一方加密的數(shù)據(jù)只能由另一方解密。
公鑰加密、私鑰解密，稱(chēng)為“加密”；私鑰加密、公鑰解密，稱(chēng)為“簽名”。公鑰密碼體制是目前唯一同時(shí)具備了加密與簽名功能的密碼體制。
2、消息摘要、數(shù)字簽名、數(shù)字證書(shū)的含義：
消息摘要又稱(chēng)數(shù)字指紋，就是對(duì)一個(gè)消息做SHA/MD5算法，這個(gè)值是唯一的；
一個(gè)高效的數(shù)字簽名技術(shù) = 消息摘要技術(shù) + 非對(duì)稱(chēng)加密技術(shù)（RSA算法）
數(shù)字證書(shū)中包含了證書(shū)持有者的信息、持有者的公鑰、證書(shū)簽發(fā)機(jī)構(gòu)（CA）的信息、CA機(jī)構(gòu)對(duì)證書(shū)本身的簽名信息以及其他一些信息，主要用于解決公鑰的安全發(fā)放問(wèn)題
在Android簽名之后，其中SF就是簽名文件，RSA就是證書(shū)文件，我們可以用openssl來(lái)查看RSA文件中的證書(shū)信息和公鑰信息
Android APK中的CERT.RSA證書(shū)是自簽名的，并不需要這個(gè)證書(shū)是第三方權(quán)威機(jī)構(gòu)發(fā)布或者認(rèn)證的
3、Android中的簽名有兩種方式：jarsigner和signapk。這兩種方式的區(qū)別是：
jarsigner簽名時(shí)，需要的是keystore文件，而signapk簽名的時(shí)候是pk8,x509.pem文件
jarsigner簽名之后的SF和RSA文件名默認(rèn)是keystore的別名，而signapk簽名之后文件名是固定的:CERT
keystore文件和pk8,x509.pem文件之間可以互相轉(zhuǎn)化
4、新簽名方案v2：
v2是一種全文件簽名方案，對(duì)整個(gè)zip文件（包括zip元數(shù)據(jù)）進(jìn)行簽名
v2方案下，zipalign需要在簽名之前執(zhí)行
v2的簽名工具-apksigner，位于sdk的build-tools目錄下，但由于v2是Android7.0之后才推出的，所以只有版本>25的sdk中才能找到apksigner.jar
為了兼容7.0以下設(shè)備，需要同時(shí)使用v1和v2簽名。此時(shí)，在7.0及以上設(shè)備中只會(huì)驗(yàn)證v2簽名，如果試圖刪除v2簽名保留v1簽名，系統(tǒng)同樣會(huì)驗(yàn)證不通過(guò)，即“防回滾保護(hù)”；而在7.0以下設(shè)備中，則只會(huì)驗(yàn)證v1簽名
文/Mob開(kāi)發(fā)者平臺(tái) Android開(kāi)發(fā)專(zhuān)家 魏士杰
以上就是關(guān)于pos機(jī)出現(xiàn)簽名摘要錯(cuò)誤,梳理3個(gè)知識(shí)點(diǎn)讓你了解Android簽名機(jī)制的知識(shí)，后面我們會(huì)繼續(xù)為大家整理關(guān)于pos機(jī)出現(xiàn)簽名摘要錯(cuò)誤的知識(shí)，希望能夠幫助到大家！
