網(wǎng)上有很多關(guān)于pos機出現(xiàn)簽名摘要錯誤,梳理3個知識點讓你了解Android簽名機制的知識，也有很多人為大家解答關(guān)于pos機出現(xiàn)簽名摘要錯誤的問題，今天pos機之家(www.dsth100338.com)為大家整理了關(guān)于這方面的知識，讓我們一起來看下吧!

本文目錄一覽：

1、pos機出現(xiàn)簽名摘要錯誤

pos機出現(xiàn)簽名摘要錯誤

在介紹簽名機制前，需要首先了解一下消息摘要、簽名文件、數(shù)字證書的知識。

1、消息摘要 - Message Digest

消息摘要（Message Digest），又稱數(shù)字摘要（Digital Digest）或數(shù)字指紋（Finger Print）。簡單來說，消息摘要就是在消息數(shù)據(jù)上，執(zhí)行一個單向的Hash函數(shù)，生成一個固定長度的Hash值，這個Hash值即是消息摘要。關(guān)于這個Hash函數(shù)，我們來看看維基百科上的定義：

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ù)就是消息摘要算法。它有以下特征：

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

消息摘要看起來是“隨機的”。這些比特看上去是胡亂的雜湊在一起的?？梢杂么罅康妮斎雭頇z驗其輸出是否相同，一般，不同的輸入會有不同的輸出，而且輸出的摘要消息可以通過隨機性檢驗。但是，一個摘要并不是真正隨機的，因為用相同的算法對相同的消息求兩次摘要，其結(jié)果必然相同；而若是真正隨機的，則無論如何都是無法重現(xiàn)的。因此消息摘要是“偽隨機的”。

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

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

正是由于以上特點，消息摘要算法被廣泛應(yīng)用在“數(shù)字簽名”領(lǐng)域，作為對明文的摘要算法。著名的消息摘要算法有RSA公司的MD5算法和SHA-1算法及其大量的變體。

2、數(shù)字簽名 - Signature

數(shù)字簽名方案是一種以電子形式存儲消息簽名的方法。一個完整的數(shù)字簽名方案應(yīng)該由兩部分組成：簽名算法和驗證算法。在講數(shù)字簽名之前，我們先簡單介紹幾個相關(guān)知識點：“公鑰密碼體制”、“對稱加密算法”、“非對稱加密算法”。

公鑰密碼體制(public-key cryptography)

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

加密：通過加密算法和公鑰對內(nèi)容(或者說明文)進行加密，得到密文。加密過程需要用到公鑰。

解密：通過解密算法和私鑰對密文進行解密，得到明文。解密過程需要用到解密算法和私鑰。注意，由公鑰加密的內(nèi)容，只能由私鑰進行解密，也就是說，由公鑰加密的內(nèi)容，如果不知道私鑰，是無法解密的。

公 鑰密碼體制的公鑰和算法都是公開的(這是為什么叫公鑰密碼體制的原因)，私鑰是保密的。大家都以使用公鑰進行加密，但是只有私鑰的持有者才能解密。在實際 的使用中，有需要的人會生成一對公鑰和私鑰，把公鑰發(fā)布出去給別人使用，自己保留私鑰。目前使用最廣泛的公鑰密碼體制是RSA密碼體制。

對稱加密算法(symmetric key algorithms)

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

非對稱加密算法(asymmetric key algorithms)

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

RSA簡介

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

加密：公鑰加密，私鑰解密的過程，稱為“加密”。因為公鑰是公開的，任何公鑰持有者都可以將想要發(fā)送給私鑰持有者的信息進行加密后發(fā)送，而這個信息只有私鑰持有者才能解密。

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

數(shù)字簽名

事實上，任何一個公鑰密碼體制都可以單獨地作為一種數(shù)字簽名方案使用。如RSA作為數(shù)字簽名方案使用時，可以定義如下：

這種簽名實際上就是用信源的私鑰加密消息，加密后的消息即成了簽體；而用對應(yīng)的公鑰進 行驗證，若公鑰解密后的消息與原來的消息相同，則消息是完整的，否則消息不完整。它正好和公鑰密碼用于消息保密是相反的過程。因為只有信源才擁有自己地私 鑰，別人無法重新加密源消息，所以即使有人截獲且更改了源消息，也無法重新生成簽體，因為只有用信源的私鑰才能形成正確地簽體。同樣信宿只要驗證用信源的 公鑰解密的消息是否與明文消息相同，就可以知道消息是否被更改過，而且可以認(rèn)證消息是否是確實來自意定的信源，還可以使信源不能否認(rèn)曾經(jīng)發(fā)送的消息。所以 這樣可以完成數(shù)字簽名的功能。

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

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

這個過程是：

用摘要算法對消息進行摘要。

再把摘要值用信源的私鑰加密。

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

先把接收到的原始消息用同樣的摘要算法摘要，形成“準(zhǔn)簽體”。

對附加上的那段數(shù)字簽名，使用預(yù)先得到的公鑰解密。

比較前兩步所得到的兩段消息是否一致。如果一致，則表明消息確實是期望的發(fā)送者發(fā)的，且內(nèi)容沒有被篡改過；相反，如果不一致，則表明傳送的過程中一定出了問題，消息不可信。

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

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

3、數(shù)字證書 - Certificate

通過數(shù)字簽名技術(shù)，確實可以解決可靠通信的問題。一旦驗簽通過，接收者就能確信該消息是期望的發(fā)送者發(fā)送的，而發(fā)送者也不能否認(rèn)曾經(jīng)發(fā)送過該消息。大家有沒有注意到，前面講的數(shù)字簽名方法，有一個前提，就是消息的接收者必須事先得到正確的公鑰。如果一開始公鑰就被別人篡改了，那壞人就會被你當(dāng)成好人，而真正的消息發(fā)送者給你發(fā)的消息會被你視作無效的。而且，很多時候根本就不具備事先溝通公鑰的信息通道。那么如何保證公鑰的安全可信呢？這就要靠數(shù)字證書來解決了。

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

證書的發(fā)布機構(gòu)（Issuer）

- 該證書是由哪個機構(gòu)（CA中心）頒發(fā)的。

證書的有效期（Validity）

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

證書所有人的公鑰（Public-Key）

- 該證書所有人想要公布出去的公鑰。

證書所有人的名稱（Subject）

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

證書所使用的簽名算法（Signature algorithm）

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

證書發(fā)行者對證書的數(shù)字簽名（Thumbprint）

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

可以看出，數(shù)字證書本身也用到了數(shù)字簽名技術(shù)，只不過簽名的內(nèi)容是 整個證書（里面包含了證書所有者的公鑰以及其他一些內(nèi)容）。與普通數(shù)字簽名不同的是，數(shù)字證書的簽名者不是隨隨便便一個普通機構(gòu)，而是CA機構(gòu)。這就好像 你的大學(xué)畢業(yè)證書上簽名的一般都是德高望重的校長一樣。一般來說，這些CA機構(gòu)的根證書已經(jīng)在設(shè)備出廠前預(yù)先安裝到了你的設(shè)備上了。所以，數(shù)字證書可以保 證證書里的公鑰確實是這個證書所有者的，或者證書可以用來確認(rèn)對方的身份。可見，數(shù)字證書主要是用來解決公鑰的安全發(fā)放問題。

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

1、簽名工具

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

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

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

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

還有一個需要注意的知識點，如果我們查看一個keystore文件的內(nèi)容，會發(fā)現(xiàn)里面包含有一個MD5和SHA1摘要，這個就是keystore文件中私鑰的數(shù)據(jù)摘要，這個信息也是我們在申請很多開發(fā)平臺賬號時需要填入的信息。

2、簽名過程

首先我們?nèi)我膺x取一個簽名后的APK（SMSSDKSample-release.apk）解壓：

在META-INF文件夾下有三個文件：MANIFEST.MF、CERT.SF、CERT.RSA。它們就是簽名過程中生成的文件，姑且叫他們“簽名三兄弟”吧，把它們搞清楚了，你就精通簽名了。

（1）MANIFEST.MF

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

（2）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編碼

對于SHA1-Digest值的驗證可以手動進行，將MANIFEST.MF中任意一個塊的內(nèi)容復(fù)制并保存在一個新的文檔中，注意文末需要加兩個換行（這是由signapk的源碼決定的）

保存文件，然后對該文件計算其SHA1值后使用Base64編碼：

得到的值就是CERT.SF中相應(yīng)條目的SHA1-Digest的值：

（3）CERT.RSA

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

什么是自簽名證書

所謂自簽名證書是指自己給自己頒發(fā)的證書，即公鑰證書中Issuer（發(fā)布者）和 Subject（所有者）是相同的。當(dāng)然，APK也可以采用由CA頒發(fā)私鑰證書進行簽名。采用非自簽名時，最終APK的公鑰證書中就會包含證書鏈，并且會 存在多余一個證書，證書間通過Issuer與Subject進行關(guān)聯(lián)，Issuer負責(zé)對Subject進行認(rèn)證。當(dāng)安裝APK時，系統(tǒng)只會用位于證書鏈 中最底層的證書對APK進行校驗，但并不會驗證證書鏈的有效性。在Https通信中使用自簽名證書時瀏覽器的顯示效果：

這里我們看到的都是二進制文件，因為RSA文件加密了，所以我們需要用openssl命令才能查看其內(nèi)容：

openssl pkcs7 -inform DER -in /Users/jackie/Downloads/apk簽名機制/SMSSDKSample-release_new/original/META-INF/DEMOKEY_.RSA -text -noout -print_certs

關(guān)于這些信息，可以看下面這張圖：

綜上所述，一個完整的簽名過程如下所示：

3、簽名驗證過程

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

（1）檢查apk中包含的所有文件，對應(yīng)的摘要值與MANIFEST.MF文件中記錄的值一致。

（2）使用證書文件（RSA文件）檢驗簽名文件（SF文件）沒有被修改過。

（3）使用簽名文件（SF文件）檢驗MF文件沒有被修改過。

綜上所述，一個完整的簽名驗證過程如下所示：

為什么使用這樣的簽名流程呢？

我們假設(shè)一下，首先，如果你改變了apk包中的任何文件，那么在apk安裝校驗時，改變后的文件摘要信息與MANIFEST.MF的檢驗信息不同，于是驗證失敗，程序就不能成功安裝。

其次，如果你對更改過的文件相應(yīng)的算出新的摘要值，然后更改MANIFEST.MF文件里面對應(yīng)的屬性值，那么必定與CERT.SF文件中算出的摘要值不一樣，照樣驗證失敗。

最后，如果你還不死心，繼續(xù)計算MANIFEST.MF的摘要值，相應(yīng)的更改CERT.SF里面的值，那么數(shù)字簽名值必定與CERT.RSA文件中記錄的不一樣，還是失敗。

那么能不能繼續(xù)偽造數(shù)字簽名呢？不可能，因為沒有數(shù)字證書對應(yīng)的私鑰。

在 Android 7.0 Nougat 中引入了全新的 APK Signature Scheme v2。

APK 簽名方案 v2 是一種全文件簽名方案，該方案能夠發(fā)現(xiàn)對 APK 的受保護部分進行的所有更改，從而有助于加快驗證速度并增強完整性保證。

1、原因

為什么谷歌要做這個事情呢？第一點毋庸置疑，肯定是處于安全性的考慮，之前的校驗方式開發(fā)者可以在打包之后對apk做很多處理，第二為了性能考慮，安裝校驗的時候不需要再解壓縮校驗，從而提升安裝速度。

2、v2帶來了什么變化

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

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

3、新的簽名方案就是一種擴展的Zip格式

使用 APK 簽名方案 v2 進行簽名時，會在 APK 文件中插入一個 APK 簽名分塊，該分塊位于“ZIP 中央目錄”部分之前并緊鄰該部分。在“APK 簽名分塊”內(nèi)，v2 簽名和簽名者身份信息會存儲在 APK 簽名方案 v2 分塊中。

4、受完整性保護的內(nèi)容

為了保護APK內(nèi)容，整個APK（zip文件格式）被分為以下4個區(qū)塊：

ZIP 條目的內(nèi)容（從偏移量 0 處開始一直到“APK 簽名分塊”的起始位置）

APK 簽名分塊

ZIP 中央目錄

ZIP 中央目錄結(jié)尾

APK 簽名方案 v2 負責(zé)保護第 1、3、4 部分的完整性，以及第 2 部分包含的“APK 簽名方案 v2 分塊”中的 signed data 分塊的完整性。

第 1、3 和 4 部分的完整性通過其內(nèi)容的一個或多個摘要來保護，這些摘要存儲在 signed data 分塊中，而這些分塊則通過一個或多個簽名來保護。

5、新舊簽名方案的兼容

新的簽名格式向后兼容，因此，使用這種新格式簽名的 APK 可在更低版本的 Android 設(shè)備上進行安裝（會直接忽略添加到 APK 的額外數(shù)據(jù)），但前提是這些 APK 還帶有 v1 簽名。

驗 證程序會對照存儲在“APK 簽名分塊”中的 v2 簽名對 APK 的全文件哈希進行驗證。該哈希涵蓋除“APK 簽名分塊”（其中包含 v2 簽名）之外的所有內(nèi)容。在“APK 簽名分塊”以外對 APK 進行的任何修改都會使 APK 的 v2 簽名作廢。v2 簽名被刪除的 APK 也會被拒絕，因為 v1 簽名指明相應(yīng) APK 帶有 v2 簽名，所以 Android Nougat 及更高版本會拒絕使用 v1 簽名驗證 APK。這就是所謂的“防回滾保護”。

防回滾保護

攻擊者可能會試圖在支持對帶 v2 簽名的 APK 進行驗證的 Android 平臺上將帶 v2 簽名的 APK 作為帶 v1 簽名的 APK 進行驗證。為了防范此類攻擊，帶 v2 簽名的 APK 如果還帶 v1 簽名，其 META-INF/*.SF 文件的主要部分中必須包含 X-Android-APK-Signed 屬性。該屬性的值是一組以英文逗號分隔的 APK 簽名方案 ID（v2 方案的 ID 為 2）。在驗證 v1 簽名時，對于此組中驗證程序首選的 APK 簽名方案（例如，v2 方案），如果 APK 沒有相應(yīng)的簽名，APK 驗證程序必須要拒絕這些 APK。此項保護依賴于內(nèi)容 META-INF/*.SF 文件受 v1 簽名保護這一事實。

6、新簽名方案v2對現(xiàn)存的渠道包生成工具的影響

之前的渠道包生成方案是通過在META-INF目錄下添加空文件，用空文件的名稱來作為渠道的唯一標(biāo)識。但在新的應(yīng)用簽名方案下META-INF已經(jīng)被列入了保護區(qū)了，向META-INF添加空文件的方案會對區(qū)塊1、3、4都會有影響。

另外一種比較流行的渠道包快速生成方案（修改Zip的注釋）也因為上述原因，無法在新的應(yīng)用簽名方案下進行正常工作。

如果新簽名方案v2后續(xù)改成強制要求，那現(xiàn)有的生成渠道包的方式就會無法工作，難道要退回到解放前嗎？

從 上面的描述可以看到，區(qū)塊1、3、4都是被保護的，任何針對這3個區(qū)塊的修改都會被新簽名方案v2檢測到，但區(qū)塊2（APK Signing Block）是不受簽名校驗規(guī)則保護的。美團的新一代打渠道包工具Walle就是往區(qū)塊2寫入一個自定義的ID-value，在App運行階段，可以通過 ZIP的EOCD（End of central directory）、Central directory等結(jié)構(gòu)中的信息（涉及ZIP格式的相關(guān)知識，這里不做展開描述）找到我們自己添加的ID-value，從而實現(xiàn)獲取渠道信息的功能，來 應(yīng)對新簽名方案v2的。

1、公鑰密碼體制：

公鑰密碼體制的公鑰和算法都是公開的，私鑰是保密的。一方加密的數(shù)據(jù)只能由另一方解密。

公鑰加密、私鑰解密，稱為“加密”；私鑰加密、公鑰解密，稱為“簽名”。公鑰密碼體制是目前唯一同時具備了加密與簽名功能的密碼體制。

2、消息摘要、數(shù)字簽名、數(shù)字證書的含義：

消息摘要又稱數(shù)字指紋，就是對一個消息做SHA/MD5算法，這個值是唯一的；

一個高效的數(shù)字簽名技術(shù) = 消息摘要技術(shù) + 非對稱加密技術(shù)（RSA算法）

數(shù)字證書中包含了證書持有者的信息、持有者的公鑰、證書簽發(fā)機構(gòu)（CA）的信息、CA機構(gòu)對證書本身的簽名信息以及其他一些信息，主要用于解決公鑰的安全發(fā)放問題

在Android簽名之后，其中SF就是簽名文件，RSA就是證書文件，我們可以用openssl來查看RSA文件中的證書信息和公鑰信息

Android APK中的CERT.RSA證書是自簽名的，并不需要這個證書是第三方權(quán)威機構(gòu)發(fā)布或者認(rèn)證的

3、Android中的簽名有兩種方式：jarsigner和signapk。這兩種方式的區(qū)別是：

jarsigner簽名時，需要的是keystore文件，而signapk簽名的時候是pk8,x509.pem文件

jarsigner簽名之后的SF和RSA文件名默認(rèn)是keystore的別名，而signapk簽名之后文件名是固定的:CERT

keystore文件和pk8,x509.pem文件之間可以互相轉(zhuǎn)化

4、新簽名方案v2：

v2是一種全文件簽名方案，對整個zip文件（包括zip元數(shù)據(jù)）進行簽名

v2方案下，zipalign需要在簽名之前執(zhí)行

v2的簽名工具-apksigner，位于sdk的build-tools目錄下，但由于v2是Android7.0之后才推出的，所以只有版本>25的sdk中才能找到apksigner.jar

為了兼容7.0以下設(shè)備，需要同時使用v1和v2簽名。此時，在7.0及以上設(shè)備中只會驗證v2簽名，如果試圖刪除v2簽名保留v1簽名，系統(tǒng)同樣會驗證不通過，即“防回滾保護”；而在7.0以下設(shè)備中，則只會驗證v1簽名

文/Mob開發(fā)者平臺 Android開發(fā)專家 魏士杰

以上就是關(guān)于pos機出現(xiàn)簽名摘要錯誤,梳理3個知識點讓你了解Android簽名機制的知識，后面我們會繼續(xù)為大家整理關(guān)于pos機出現(xiàn)簽名摘要錯誤的知識，希望能夠幫助到大家！