android簽名校驗

⑴ Android中APK簽名工具之jarsigner和apksigner詳解

轉自 https://www.cnblogs.com/slysky/p/9780015.html

一.工具介紹

jarsigner是JDK提供的針對jar包簽名的通用工具,

位於JDK/bin/jarsigner.exe

apksigner是Google官方提供的針對Android apk簽名及驗證的專用工具,

位於Android SDK/build-tools/SDK版本/apksigner.bat

不管是apk包,還是jar包,本質都是zip格式的壓縮包,所以它們的簽名過程都差不多(僅限V1簽名),

以上兩個工具都可以對Android apk包進行簽名.

1.V1和V2簽名的區別

在Android Studio中點擊菜單 Build->Generate signed apk... 打包簽名有兩種簽名選項 V1(Jar Signature) V2(Full APK Signature),

從Android 7.0開始, 谷歌增加新簽名方案 V2 Scheme (APK Signature);

但Android 7.0以下版本, 只能用舊簽名方案 V1 scheme (JAR signing)

V1簽名:

V2簽名:

V2簽名優點很明顯:

注意: apksigner工具默認同時使用V1和V2簽名,以兼容Android 7.0以下版本

2.zipalign和V2簽名

位於Android SDK/build-tools/SDK版本/zipalign.exe

zipalign 是對zip包對齊的工具,使APK包內未壓縮的數據有序排列對齊,從而減少APP運行時內存消耗

zipalign -v 4 in.apk out.apk //4位元組對齊優化

zipalign -c -v 4 in.apk //檢查APK是否對齊

zipalign可以在V1簽名後執行

但zipalign不能在V2簽名後執行,只能在V2簽名之前執行！！！

二.簽名步驟

1.生成密鑰對(已有密鑰庫,可忽略)

Android Studio在Debug時,對App簽名都會使用一個默認的密鑰庫:

1.生成密鑰對

進入JDK/bin, 輸入命令

參數:

提示: 可重復使用此條命令,在同一密鑰庫中創建多條密鑰對
例如: 在debug.keystore中新增一對密鑰,別名是release

keytool -genkeypair -keystore debug.keystore -alias release -validity 30000

2.查看密鑰庫

進入JDK/bin, 輸入命令

keytool -list -v -keystore 密鑰庫名

參數:

例如:
keytool -list -v -keystore debug.keystore

現在debug.keystore密鑰庫中有兩對密鑰, 別名分別是androiddebugkey release

2.簽名

1.方法一(jarsigner,只支持V1簽名)

進入JDK/bin, 輸入命令

從JDK7開始, jarsigner默認演算法是SHA256, 但Android 4.2以下不支持該演算法,

所以需要修改演算法, 添加參數 -digestalg SHA1 -sigalg SHA1withRSA

參數:

例如:

用JDK7及以上jarsigner簽名,不支持Android 4.2 以下

jarsigner -keystore debug.keystore MyApp.apk androiddebugkey

用JDK7及以上jarsigner簽名,兼容Android 4.2 以下

jarsigner -keystore debug.keystore -digestalg SHA1 -sigalg SHA1withRSA MyApp.apk androiddebugkey

2.方法二(apksigner,默認同時使用V1和V2簽名)

進入Android SDK/build-tools/SDK版本, 輸入命令

若密鑰庫中有多個密鑰對,則必須指定密鑰別名

禁用V2簽名

apksigner sign --v2-signing-enabled false --ks 密鑰庫名 xxx.apk

參數:

例如:

在debug.keystore密鑰庫只有一個密鑰對

apksigner sign --ks debug.keystore MyApp.apk

在debug.keystore密鑰庫中有多個密鑰對,所以必須指定密鑰別名

apksigner sign --ks debug.keystore --ks-key-alias androiddebugkey MyApp.apk

3.簽名驗證

1.方法一(keytool,只支持V1簽名校驗)

進入JDK/bin, 輸入命令

keytool -printcert -jarfile MyApp.apk (顯示簽名證書信息)

參數:

2.方法二(apksigner,支持V1和V2簽名校驗)

進入Android SDK/build-tools/SDK版本, 輸入命令

apksigner verify -v --print-certs xxx.apk

參數:

例如:

apksigner verify -v MyApp.apk

⑵ android 系統簽名

也有提到怎麼單獨給一個apk簽名，這里補充一下android的簽名許可權控制機制。

android的標准簽名key有：

     testkey

     media

    latform

    hared

    以上的四種，可以在源碼的/build/target/proct/security裡面看到對應的密鑰，其中shared.pk8代表私鑰，shared.x509.pem公鑰，一定是成對出現的。

    其中testkey是作為android編譯的時候默認的簽名key，如果系統中的apk的android.mk中沒有設置LOCAL_CERTIFICATE的值，就默認使用testkey。

   而如果設置成：

   LOCAL_CERTIFICATE := platform

    就代表使用platform來簽名，這樣的話這個apk就擁有了和system相同的簽名，因為系統級別的簽名也是使用的platform來簽名，此時使用android:sharedUserId="android.uid.system"才有用！

     在/build/target/proct/security目錄下有個README，裡面有說怎麼製作這些key以及使用問題（android4.2）：

     從上面可以看出來在源碼下的/development/tools目錄下有個make_key的腳本，通過傳入兩個參數就可以生成一對簽名用的key。

    其中第一個為key的名字，一般都默認成android本身有的，因為很多地方都默認使用了這些名字，我們自定義的話只需要對第二個參數動手腳，定義如下：

    C ---> Country Name (2 letter code) ST ---> State or Province Name (full name) L ---> Locality Name (eg, city) O ---> Organization Name (eg, company) OU ---> Organizational Unit Name (eg, section) CN ---> Common Name (eg, your name or your server』s hostname) emailAddress ---> Contact email addre

    另外在使用上面的make_key腳本生成key的過程中會提示輸入password，我的處理是不輸入，直接enter，不要密碼！後面解釋，用自定義的key替換/security下面的。

    可以看到android源碼裡面的key使用的第二個參數就是上面README裡面的，是公開的，所以要release版本的系統的話，肯定要有自己的簽名key才能起到一個安全控製作用。

    在上面提到如果apk中的編譯選項LOCAL_CERTIFICATE沒有設置的話，就會使用默認的testkey作為簽名key，我們可以修改成自己想要的key，按照上面的步驟製作一個releasekey，修改android配置在/build/core/config.mk中定義變數：

在主makefile文件裡面：

ifeq ($(DEFAULT_SYSTEM_DEV_CERTIFICATE),build/target/proct/security/releasekey)

  BUILD_VERSION_TAGS += release-key

這樣的話默認的所有簽名將會使用releasekey。

修改完之後就要編譯了，如果上面的這些key在製作的時候輸入了password就會出現如下錯誤：

我在網上找到了合理的解釋：

其實會出現這個錯誤的最根本的原因是多線程的問題。在編譯的時候為了加速一般都會執行make -jxxx，這樣本來需要手動輸入密碼的時候，由於其它線程的運行，就會導致影響當前的輸入終端，所以就會導緻密碼無法輸入的情況！

再編譯完成之後也可以在build.prop中查看到變數：

這樣處理了之後編譯出來的都是簽名過的了，系統才算是release版本

我發現我這樣處理之後，整個系統的算是全部按照我的要求簽名了。

網上看到還有另外的簽名release辦法，但是應該是針對另外的版本的，借用學習一下：

make -j4 PRODUCT-proct_mol-user dist

這個怎麼跟平時的編譯不一樣,後面多了兩個參數PRODUCT-proct_mol-user 和 dist. 編譯完成之後回在源碼/out/dist/目錄內生成個proct_mol-target_files開頭的zip文件.這就是我們需要進行簽名的文件系統.

我的proct_mol 是full_gotechcn,後面加「-user」代表的是最終用戶版本，關於這個命名以及proct_mol等可參考http://blog.csdn.net/jscese/article/details/23931159

編譯出需要簽名的zip壓縮包之後，就是利用/security下面的准備的key進行簽名了：

./build/tools/releasetools/sign_target_files_apks -d /build/target/proct/security  out/dist/full_gotechcn-target_files.zip   out/dist/signed_target_files.zi

簽名目標文件 輸出成signed_target_files.zi

如果出現某些apk出錯，可以通過在full_gotechcn-target_files.zip前面加參數"-e =" 來過濾這些apk.

然後再通過image的腳本生成imag的zip文件，這種方式不適用與我目前的工程源碼，沒有做過多驗證！

Android簽名機制可劃分為兩部分：（1）ROM簽名機制；（2）第三方APK簽名機制。

Android APK實際上是一個jar包，而jar包又是一個zip包。APK包的簽名實際上使用的是jar包的簽名機制：在zip中添加一個META的子目錄，其中存放簽名信息；而簽名方法是為zip包中的每個文件計算其HASH值，得到簽名文件(*.sf)，然後對簽名文件(.sf)進行簽名並把簽名保存在簽名塊文件(*.dsa)中。

在編譯Android源碼生成ROM的過程中，會使用build/target/proct/security目錄中的4個key（media, platform, shared, testkey）來對apk進行簽名。其中，*.pk8是二進制形式（DER）的私鑰，*.x509.pem是對應的X509公鑰證書（BASE64編碼）。build/target/proct/security目錄中的這幾個默認key是沒有密碼保護的，只能用於debug版本的ROM。

要生成Release版本的ROM，可先生成TargetFiles，再使用帶密碼的key對TargetFiles重新簽名，最後由重簽名的TargetFiles來生成最終的ROM。

可以使用Android源碼樹中自帶的工具「development/tools/make_key」來生成帶密碼的RSA公私鑰對（實際上是通過openssl來生成的）: $ development/tools/make_key media 『/C=CN/ST=Sichuan/L=Cheng/O=MyOrg/OU=MyDepartment/CN=MyName』 上面的命令將生成一個二進制形式（DER）的私鑰文件「media.pk8」和一個對應的X509公鑰證書文件「media.x509.pem」。其中，/C表示「Country Code」，/ST表示「State or Province」，/L表示「City or Locality」，/O表示「Organization」，/OU表示「Organizational Unit」，/CN表示「Name」。前面的命令生成的RSA公鑰的e值為3，可以修改development/tools/make_key腳本來使用F4 (0×10001)作為e值（openssl genrsa的-3參數改為-f4）。

也可以使用JDK中的keytool來生成公私鑰對，第三方APK簽名一般都是通過keytool來生成公私鑰對的。

可以使用openssl x509命令來查看公鑰證書的詳細信息： $ openssl x509 -in media.x509.pem -text -noout or, $ openssl x509 -in media.x509.pem -inform PEM -text -noout

還可以使用JDK中的keytool來查看公鑰證書內容，但其輸出內容沒有openssl x509全面： $ keytool -printcert -v -file media.x509.pem

有了key之後，可以使用工具「build/tools/releasetools/sign_target_files」來對TargetFiles重新簽名： $ build/tools/releasetools/sign_target_files_apks -d new_keys_dir -o target_files.zip target_files_resigned.zip 其中，new_keys_dir目錄中需要有四個key（media, platform, shared, releasekey）。注意：這里的releasekey將代替默認的testkey（請參考build/tools/releasetools/sign_target_files腳本實現），也就是說，如果某個apk的Android.mk文件中的LOCAL_CERTIFICATE為testkey，那麼在生成TargetFiles時是使用的build/target/proct/security/testkey來簽名的，這里重新簽名時將使用new_keys_dir/releasekey來簽名。

uild/tools/releasetools/sign_target_files_apks是通過host/linux-x86/framework/signapk.jar來完成簽名的。也可以直接使用host/linux-x86/framework/signapk.jar來對某個apk進行簽名： $ java -jar signapk [-w] publickey.x509[.pem] privatekey.pk8 input.jar output.jar 其中，」-w」表示還對整個apk包(zip包）進行簽名，並把簽名放在zip包的comment中。

對於第三方應用開發者而言，對APK簽名相對要簡單得多。第三方應用開發一般採用JDK中的keytool和jarsigner來完成簽名密鑰的管理和APK的簽名。

使用keytool來生成存儲有公私鑰對的keystore： $ keytool -genkey -v -keystore my-release-key.keystore -alias mykey -keyalg RSA -keysize 2048 -validity 10000

查看生成的密鑰信息： $ keytool -list -keystore my-release-key.keystore -alias mykey -v or, $ keytool -list -keystore my-release-key.keystore -alias mykey -rfc （註：獲取Base64格式的公鑰證書，RFC 1421）

導出公鑰證書： $ keytool -export -keystore mystore -alias mykey -file my.der （註：二進制格式公鑰證書，DER） $ keytool -export -keystore mystore -alias mykey -file my.pem -rfc （註：Base64格式公鑰證書，PEM）

對APK進行簽名： $ jarsigner -verbose -keystore my-release-key.keystore my_application.apk mykey

驗證簽名： $ jarsigner -verify -verbose -certs my_application.apk

在進行Android二次開發時，有時需要把build/target/proct/security下面的公私鑰對轉換為keystore的形式，可以參考這篇文章：把Android源碼中的密碼對轉換為keystore的方法。

⑶ 一文弄懂關於證書，簽名，ssl，android包簽名機制。

所有的概念都基於一個非常重要的基礎：

rsa 非對稱加密演算法 ：

先感受下幾個概念

PKI。

PKI是公鑰基礎設施（Public Key Infrastructure) 包括PKI策略、軟硬體系統、證書機構CA、注冊機構RA、證書發布系統和PKI應用等。

我們關注就倆東西： PKCS 證書機構CA 。前者是定義加密演算法，簽名，證書相關的各種事情採用的協議。後者可以為我們頒發權威的證書。

PKCS ：
PKCS（The Public-Key Cryptography Standards ）是由美國RSA數據安全公司及其合作夥伴制定的一組公鑰密碼學標准，其中包括證書申請、證書更新、證書作廢表發布、擴展證書內容以及數字簽名、數字信封的格式等方面的一系列相關協議。RSA演算法可以做加密、解密、簽名、驗證，還有RSA的密鑰對存儲。這些都需要標准來規范，如何輸入，如何輸出，如何存儲等。

PKCS。全稱是公鑰密碼學標准， 目前共發布過 15 個標准，這些標准都是協議。總結一下 就是對加密演算法，簽名，證書協議的描述。下面列舉一些常用的協議，這些協議在本文都會對應上。

這些協議具體的實現就體現在openssl等工具中， 以及jdk工具keytool jdk java第三方庫bouncycastle。

比如用openssl 如何生成公/私鑰(PKCS#1)、簽名(PKCS#1 )、簽名請求文件（KCS#10）、 帶口令的私鑰（PKCS#8）。 含私鑰的證書（PKCS#12）、證書庫（PKCS#12）

其中涉及到演算法的基礎協議PKCS#1等，由於涉及到密碼學原理所以我們並不需要深究它，只要知道怎麼做就可以了。

現實中我們要解決這樣一種情況:

客戶端和伺服器之間的數據要進行加密。需要兩個達成同一個對稱秘鑰加密才行，那麼這個秘鑰如何生成，並在兩邊都能拿到，並保證傳輸過程中不被泄露。 這就用到非對稱加密了。 後續的傳輸，就能用這個 對稱秘鑰來加密和解密了。

還有這樣一個問題：

就是客戶端如何判斷服務端是否是合法的服務端。這就需要服務端有個id來證明它，而這個id 就是證書，而且必須是權威機構頒發的才能算是合法的。
因為客戶端即瀏覽器，認定證書合法的規則必須通過第三方來確認 即ca頒發的證書。否則就我可能進了一個假網站。

而這兩個問題 都是ssl協議要解決的內容。

所以ssl協議做了兩件事情，一是驗證身份，二是協商對稱秘鑰，並安全的傳輸。 而實現這個過程的關鍵數據模型就是證書， 通過證書中的ca對證書的簽名，實現了身份驗證，通過證書中的公鑰，實現對對稱秘鑰加密，從而實現數據保密。 其實還順手做了一件事情就是通過解密簽名比對hash，保證了數據完整性。

明白ssl協議 首先明白幾個重要的概念：

證書： 顧名思義就是提供了一種在Internet上驗證通信實體身份的方式，數字證書不是數字身份證，由權威公正的第三方機構，即CA（例如中國各地方的CA公司）中心簽發的證書， 就是可以認定是合法身份的。客戶端不需要證書。 證書是用來驗證服務端的。

一般的證書都是x509格式證書，這是一種標準的證書，可以和其他證書類型互相轉換。完整來說證書包含，證書的內容，包括 版本號， 證書序列號， hash演算法， 發行者名稱，有效期， 公鑰演算法，公鑰，簽名（證書原文以及原文hash一起簽名）而這個內容以及格式 都是標准化的，即x509格式 是一種標準的格式。

簽名: 就用私鑰對一段數據進行加密，得到的密文。 這一段數據在證書的應用上就是 對證書原文+原文hash進行簽名。
誰簽的名，就是用誰的私鑰進行加密。就像身份證一樣， 合法的身份證我們都依據是政府簽的，才不是假證， 那就是瀏覽器會有政府的公鑰，通過校驗（解密）簽名，如果能夠解密，就可以確定這個就是政府的簽名。就對了。

hash演算法 ：對原始數據進行某種形式的信息提取，被提取出的信息就被稱作原始數據的消息摘要。比如，MD5和SHA-1及其大量的變體。 hash演算法具有不可逆性，無法從摘要中恢復出任何的原始消息。長度總是固定的。MD5演算法摘要的消息有128個比特位，SHA-1演算法摘要的消息最終有160比特位的輸出。

ca機構： 權威證書頒發機構，瀏覽器存有ca的公鑰，瀏覽器以此公鑰來驗證服務端證書的合法性。

證書的獲取： 生成證書申請文件.csr（涉及到PKCS#10定義的規范）後向ca機構申請。 或者自己直接通過生成私鑰就可以一步到位生成自簽名證書。 自簽名證書就是用自己的私鑰來簽名證書。

那麼為了體現到 證書身份認證、數據完整、保密性三大特性 ，證書的簡化模型可以認為包含以下兩個要素：伺服器公鑰，ca的簽名（被ca私鑰加密過的證書原文+原文hash），

身份認證：
瀏覽器存有ca公鑰，用ca公鑰解密網站發給你的證書中的簽名。如果能解密，說明該證書由ca頒發，證書合法。 否則瀏覽器就會報警告，問你是否信任這個證書，也就是這個網站。這時候的證書可以是任何人簽發的，可以自己簽發的。 但是中間人攻擊。 完全偽造新的證書， 這就沒有辦法了。 所以還是信任證書的時候要謹慎。

數據完整：
如果你信任該證書的話，這時候就會用證書中的公鑰去解密簽名，如果是ca簽發的證書，那麼之前就已經通過ca的公鑰去解密簽名了。 然後得到證書hash，然後在瀏覽器重新對證書做hash，兩者比對一致的話，說明證書數據沒有被篡改。

保密性：
使用證書的公鑰對對稱秘鑰加密保證傳輸安全，對稱秘鑰生成後，後續的傳輸會通過對稱秘鑰來在服務端和客戶端的加解密。

那麼ssl協議的具體過程就是：

4.網站接收瀏覽器發來的數據之後 使用自己的私鑰校驗簽名，並對原文進行hash 與解密出的hash 做比對檢查完整性。然後發送編碼改變通知，伺服器握手結束通知（所有內容做hash ）。 發送給客戶端校驗。

5 客戶端校驗，校驗成功後，之後就用 對稱秘鑰進行通信了。

總共的過程是 c-s-c- s-c 四次握手。

四次握手簡單來說分別是：
1.請求獲取證書
2.服務端返回證書，客戶端驗證了證書的合法性和完整性，同時生成了對稱秘鑰。
3.客戶端把加密的 對稱秘鑰發給伺服器。伺服器檢查真實性和完整性。
4.服務端返回握手結束通知，客戶端再檢查一次真實性和完整性。

前兩次握手是明文， 後兩次握手是密文。 所以都要檢查身份真實性和數據完整性。

ca的作用：
ca起到一個權威中間人的角色，如果脫離了ca， 那麼證書還是證書，還能加密，保證數據完整性。 但是無法應用在客戶端去認定伺服器身份合法這個場景下。

  

下面就詳細說下 脫離了ca簽發的證書的應用：
  

自簽名證書：

證書如果沒有權威機構的簽名，就是沒有權威機構給你簽發身份證。 那麼這時候身份認證的場景變了。
這時候的認證場景就變成了，不再是某個官方權威說了算，而是假設第一次碰到這個證書，會認為，這個證書與之捆綁的實體之間是合法的並做記錄。如果當這個實體下次捆綁了另一個證書，那麼就是非法的。

這種情況常用於android中安裝和校驗app的時候，會先假設第一次安裝的是合法的應用，認定這個app證書中的公鑰是合法的公鑰。然後通過自簽名的證書，校驗簽名，就能實現後續安裝是否合法以及完整性。

android中的如何對app進行身份認定和不被篡改：

android系統在安裝app時候會進行校驗applicationId，applicationId 不同會認定為不同應用。相同應用，第二次安裝會校驗證書是否和之前app的證書相同，如果相同則兩個包很可能來自同一個身份。 如果證書不同，也就是該包被另一個身份用自己的私鑰重新簽名過，就會拒絕安裝。 然後通過公鑰來解密簽名，如果能解密，說明身份是ok的。否則拒絕安裝。比對解密簽名後的hash 與apk包內的cert.sf文件(該文件是apk內所有文件生成的hash文件)是否一致，如果相同則認定為沒有被篡改。

android在提交應用商店的問題：

應用商店也會校驗 後續的上傳和第一次上傳時的證書，以及類似上述的後續的一系列校驗。防止合法的開發者平台被盜後，上傳非法應用。

android在接入第三方sdk的問題：

接入第三方sdk 會提交applicationId 和 sha1 值。 這個sha1值就是對 證書原文的簽名後的sha1，也就是證書指紋。這個證書是證書庫里最初的那個證書（x509格式），而不是對apk簽名後生成的證書(PKCS#7)。一般的證書簽名的主體是證書原文本身，而對apk簽名還額外會對apk所有文件生成的hash值文件（cert.sf）進行一次簽名。

第三方平台會記錄 applicationId 與sha1 的對應關系。 當有假冒app試圖接入時候，由於會對app內的PKCS#7證書轉換為原始的x509格式證書，重新生成sha1值，與用戶提交sha1 比對， 如果相同則說明證書很可能是ok的。 因為sha1就是證書的指紋。 之後就會通過證書中的公鑰來校驗簽名，從而最終確認身份合法性以及信息完整性。

第三方平台之所以需要用戶去提交證書指紋sha1值，多了這一步，就意味著你的證書是可以更換的，一旦更換了證書，就必須提交新的指紋給我，然後我來做匹配。而應用商店沒有這個功能， 一旦你的證書的私鑰丟了， 那就必須重新建一個新的app。

總結來看證書的身份認定機制：

在ssl協議下，這種場景是 瀏覽器用於認定合法的伺服器身份。 在自簽名證書下，需要用戶選擇是否信任該證書。

在android app採用自簽名證書的場景下， 證書起到了 假設第一次的證書合法，公鑰合法，後續如果證書不一致或不能夠完成簽名校驗，就是非法。

證書庫：

證書庫應該滿足PKCS#12協議。 但是jdk提供了製作證書的工具keytool 可以生成keystore類型的證書庫，後綴為jks。 keystore pk12可以通過keytool命令互相轉換。

證書庫是個證書的容器， 可以用來創建數字證書。 在keystore證書庫中，所有的數字證書是以一條一條(採用別名alias區別)的形式存入證書庫的。證書庫中的證書格式為pk12，即包含私鑰。 如果導出證書的話， 可以導出為x509不包含私鑰的格式 或者pk12包含私鑰的證書。 也可以也可以用-import參數加一個證書或證書鏈到信任證書。

android中一般都採用讀取證書庫的方式，通過證書庫來創建一個證書，通過alias來區分。 所以在簽名的時候，一個alias是一個證書，不同的alias是不同的證書，不要搞錯了。

幾個關系：

證書和非對稱加密演算法的關系：
證書代表一個身份的主體，包含了非對稱秘鑰體系中的公鑰，以及用私鑰對證書簽名。這種組織結構，把非對稱加密演算法從加密的功能，拓寬到了用於身份認證，信息完整性上。這體現在了證書的作用。 本質還是利用了非對稱加密演算法的特性。

ssl協議和證書的關系。
因為證書解決了客戶端對伺服器的身份認證（自簽名證書除外），同時也解決了加密，和信息完整性，所以ssl協議基於證書來實現。

⑷ Android V1及V2簽名原理簡析

Android為了保證系統及應用的安全性，在安裝APK的時候需要校驗包的完整性，同時，對於覆蓋安裝的場景還要校驗新舊是否匹配，這兩者都是通過Android簽名機制來進行保證的，本文就簡單看下Android的簽名與校驗原理，分一下幾個部分分析下：

簽名是摘要與非對稱密鑰加密相相結合的產物，摘要就像內容的一個指紋信息，一旦內容被篡改，摘要就會改變，簽名是摘要的加密結果，摘要改變，簽名也會失效。Android APK簽名也是這個道理，如果APK簽名跟內容對應不起來，Android系統就認為APK內容被篡改了，從而拒絕安裝，以保證系統的安全性。目前Android有三種簽名V1、V2（N）、V3（P），本文只看前兩種V1跟V2，對於V3的輪密先不考慮。先看下只有V1簽名後APK的樣式：

再看下只有V2簽名的APK包樣式：

同時具有V1 V2簽名：

可以看到，如果只有V2簽名，那麼APK包內容幾乎是沒有改動的，META_INF中不會有新增文件，按Google官方文檔：在使用v2簽名方案進行簽名時，會在APK文件中插入一個APK簽名分塊，該分塊位於zip中央目錄部分之前並緊鄰該部分。在APK簽名分塊內， 簽名和簽名者身份信息會存儲在APK簽名方案v2分塊中，保證整個APK文件不可修改 ，如下圖：

而V1簽名是通過META-INF中的三個文件保證簽名及信息的完整性：

V1簽名是如何保證信息的完整性呢？V1簽名主要包含三部分內容，如果狹義上說簽名跟公鑰的話，僅僅在.rsa文件中，V1簽名的三個文件其實是一套機制，不能單單拿一個來說事，

如果對APK中的資源文件進行了替換，那麼該資源的摘要必定發生改變，如果沒有修改MANIFEST.MF中的信息，那麼在安裝時候V1校驗就會失敗，無法安裝，不過如果篡改文件的同時，也修改其MANIFEST.MF中的摘要值，那麼MANIFEST.MF校驗就可以繞過。

CERT.SF個人覺得有點像冗餘，更像對文件完整性的二次保證，同繞過MANIFEST.MF一樣，.SF校驗也很容易被繞過。

CERT.RSA與CERT.SF是相互對應的，兩者名字前綴必須一致，不知道算不算一個無聊的標准。看下CERT.RSA文件內容：

CERT.RSA文件裡面存儲了證書公鑰、過期日期、發行人、加密演算法等信息，根據公鑰及加密演算法，Android系統就能計算出CERT.SF的摘要信息，其嚴格的格式如下：

從CERT.RSA中，我們能獲的證書的指紋信息，在微信分享、第三方SDK申請的時候經常用到，其實就是公鑰+開發者信息的一個簽名：

除了CERT.RSA文件，其餘兩個簽名文件其實跟keystore沒什麼關系，主要是文件自身的摘要及二次摘要，用不同的keystore進行簽名，生成的MANIFEST.MF與CERT.SF都是一樣的，不同的只有CERT.RSA簽名文件。也就是說前兩者主要保證各個文件的完整性，CERT.RSA從整體上保證APK的來源及完整性，不過META_INF中的文件不在校驗范圍中，這也是V1的一個缺點。V2簽名又是如何保證信息的完整性呢？

前面說過V1簽名中文件的完整性很容易被繞過，可以理解 單個文件完整性校驗的意義並不是很大 ，安裝的時候反而耗時，不如採用更加簡單的便捷的校驗方式。V2簽名就不針對單個文件校驗了，而是 針對APK進行校驗 ，將APK分成1M的塊，對每個塊計算值摘要，之後針對所有摘要進行摘要，再利用摘要進行簽名。

也就是說，V2摘要簽名分兩級，第一級是對APK文件的1、3 、4 部分進行摘要，第二級是對第一級的摘要集合進行摘要，然後利用秘鑰進行簽名。安裝的時候，塊摘要可以並行處理，這樣可以提高校驗速度。

APK是先摘要，再簽名，先看下摘要的定義：Message Digest：摘要是對消息數據執行一個單向Hash，從而生成一個固定長度的Hash值，這個值就是消息摘要，至於常聽到的MD5、SHA1都是摘要演算法的一種。理論上說，摘要一定會有碰撞，但只要保證有限長度內碰撞率很低就可以，這樣就能利用摘要來保證消息的完整性，只要消息被篡改，摘要一定會發生改變。但是，如果消息跟摘要同時被修改，那就無從得知了。

而數字簽名是什麼呢（公鑰數字簽名），利用非對稱加密技術，通過私鑰對摘要進行加密，產生一個字元串，這個字元串+公鑰證書就可以看做消息的數字簽名，如RSA就是常用的非對稱加密演算法。在沒有私鑰的前提下，非對稱加密演算法能確保別人無法偽造簽名，因此數字簽名也是對發送者信息真實性的一個有效證明。不過由於Android的keystore證書是自簽名的，沒有第三方權威機構認證，用戶可以自行生成keystore，Android簽名方案無法保證APK不被二次簽名。

知道了摘要跟簽名的概念後，再來看看Android的簽名文件怎麼來的？如何影響原來APK包？通過sdk中的apksign來對一個APK進行簽名的命令如下：

其主要實現在 android/platform/tools/apksig 文件夾中，主體是ApkSigner.java的sign函數，函數比較長，分幾步分析

先來看這一步，ApkUtils.findZipSections，這個函數主要是解析APK文件，獲得ZIP格式的一些簡單信息，並返回一個ZipSections，

ZipSections包含了ZIP文件格式的一些信息，比如中央目錄信息、中央目錄結尾信息等，對比到zip文件格式如下：

獲取到 ZipSections之後，就可以進一步解析APK這個ZIP包，繼續走後面的簽名流程，

可以看到先進行了一個V2簽名的檢驗，這里是用來簽名，為什麼先檢驗了一次？第一次簽名的時候會直接走這個異常邏輯分支，重復簽名的時候才能獲到取之前的V2簽名，懷疑這里獲取V2簽名的目的應該是為了排除V2簽名，並獲取V2簽名以外的數據塊，因為簽名本身不能被算入到簽名中，之後會解析中央目錄區，構建一個DefaultApkSignerEngine用於簽名

先解析中央目錄區，獲取AndroidManifest文件，獲取minSdkVersion(影響簽名演算法)，並構建DefaultApkSignerEngine，默認情況下V1 V2簽名都是打開的。

第五步與第六步的主要工作是：apk的預處理，包括目錄的一些排序之類的工作，應該是為了更高效處理簽名，預處理結束後，就開始簽名流程，首先做的是V1簽名（默認存在，除非主動關閉）：

步驟7、8、9都可以看做是V1簽名的處理邏輯，主要在V1SchemeSigner中處理，其中包括創建META-INFO文件夾下的一些簽名文件，更新中央目錄、更新中央目錄結尾等，流程不復雜，不在贅述，簡單流程就是：

這里特殊提一下重復簽名的問題： 對一個已經V1簽名的APK再次V1簽名不會有任何問題 ，原理就是：再次簽名的時候，會排除之前的簽名文件。

可以看到目錄、META-INF文件夾下的文件、sf、rsa等結尾的文件都不會被V1簽名進行處理，所以這里不用擔心多次簽名的問題。接下來就是處理V2簽名。

V2SchemeSigner處理V2簽名，邏輯比較清晰，直接對V1簽名過的APK進行分塊摘要，再集合簽名，V2簽名不會改變之前V1簽名後的任何信息，簽名後，在中央目錄前添加V2簽名塊，並更新中央目錄結尾信息，因為V2簽名後，中央目錄的偏移會再次改變：

簽名校驗的過程可以看做簽名的逆向，只不過覆蓋安裝可能還要校驗公鑰及證書信息一致，否則覆蓋安裝會失敗。簽名校驗的入口在PackageManagerService的install里，安裝官方文檔，7.0以上的手機優先檢測V2簽名，如果V2簽名不存在，再校驗V1簽名，對於7.0以下的手機，不存在V2簽名校驗機制，只會校驗V1，所以，如果你的App的miniSdkVersion<24(N)，那麼你的簽名方式必須內含V1簽名：

校驗流程就是簽名的逆向，了解簽名流程即可，本文不求甚解，有興趣自己去分析，只是額外提下覆蓋安裝，覆蓋安裝除了檢驗APK自己的完整性以外，還要校驗證書是否一致只有證書一致（同一個keystore簽名），才有可能覆蓋升級。覆蓋安裝同全新安裝相比較多了幾個校驗

這里只關心證書部分：

Android V1及V2簽名簽名原理簡析

僅供參考，歡迎指正

⑸ 如何對android的apk簽名進行驗證

方法/步驟

1
菜單菜單鍵，鍵入cmd命令進入命令模式。如圖：

2
命令模式中，進入JDK的安裝目錄的Bin子目錄下。（我的JDK安裝在E盤，所以先進入E盤，然後再進入JDK安裝目錄）

3
通過keytool.exe 工具來創建keystore庫.
輸入以下命令：
keytool -genkeypair -alias - mydemo.keystore -keyalg RSA -validity 100
-keystore mydemo.keystore
命令說明如下：
-genkeypair ：指定生成數字證實
-alias ：指定生成數字證書的別名
-keyalg：指定生成數字證書的演算法 這里如RSA演算法
-validity：指定生成數字證書的有效期
-keystore ：指定生成數字證書的存儲路徑。 （這里默認在keytool.exe 目錄下）
回車 出現如圖互動式界面 輸入數字證書費密碼 作者 公司等詳細信息
如圖 ：

4
完成後，keystore庫創建完成，你可以在指定的保存目錄下找到 如圖：

5
使用jarsigner命令對未簽名的APK安裝包進行簽名。使用JDK安裝目錄下bin子目錄下的jarsigner.exe工具來進行簽名。
然後把未簽名的apk也拷貝到此目錄。如圖：

6
使用如下命令進行簽名：
jarsigner -verbose -keystore mydemo.keystore -signedjar
-Note.apk Notes.apk mydemo.keystore
以上命令的說明：
-verbose：指定生成詳細輸出
-keystore：指定數字證書存儲路徑
-signedjar：該選項的三個參數為 簽名後的apk包 未簽名的apk包 數字證書別名
注意有效期哦。

7
簽名後的apk 如圖：

8
sdk目錄下tool目錄下使用zipalign.exe工具優化APK安裝包。
將已經簽名的apk包放在zipalign.exe同目錄下 如圖：

9
使用如下命令：
zipalign -f -v 4 -Note.apk -Notes.apk
命令說明：
-f ：指定強制覆蓋已有文件
-v 指定生成詳細輸出
4：指定檔案整理基於的位元組數 一般是4 也有基於32位的。
-Note.apk :優化前APK
-Notes.apk 優化後的APK

10
運行命令後，在該目錄下生成一個-Notes.apk,這個就是優化過的APK安裝包
，該安裝包可以對外發布。
如圖：
如果能對你有幫助，希望你能收藏和支持。

http://jingyan..com/article/3c48dd3491d91fe10be358f4.html

⑹ Android APP的簽名

Android APP的簽名

Android項目以它的包名作為唯一的標識，如果在同一部手機上安裝兩個包名相同的APP，後者就會覆蓋前面安裝的應用。為了避免Android APP被隨意覆蓋，Android要求對APP進行簽名。下面介紹對APP進行簽名的步驟

1、選擇builder菜單下的Generate Signed APK

2、彈出簽名向導對話框

3、在該對話框中選擇數字證書，如果沒有數字證書，可以點擊Create new按鈕，創建數字證書如下圖所示：

4、輸入證書的存儲路徑及文件名稱，密碼，有效年份，發布人員的姓名，單位，所在城市，省份，國家等信息，後點擊OK按鈕，如下圖所示，系統會自動帶入密碼

5、點擊Next選擇簽名後的安裝包存放路徑，構建類型，點擊finish完成安裝包的構建

注意：

v2是Android 7.0中引入了簽名版本，v1是jar Signature來自JDK，只勾選v1簽名並不會影響什麼，但是在7.0上不會使用更安全的驗證方式，只勾選V2簽名7.0以下會直接安裝完顯示未安裝，7.0以上則使用了V2的方式驗證，為了保證兼容性，可以同時勾選V1和V2。
在Debug調試版本中，默認會調用調試用的簽名證書debug.keystore，該證書默認存放在C:\Users<你的用戶名>.android下。
包名和簽名都相同的APP才可以覆蓋安裝

⑺ Android基礎『V1V2V3簽名』

基礎概念
簽名：在 APK 中寫入一個「指紋」。指紋寫入以後，APK 中有任何修改，都會導致這個指紋無效，Android 系統在安裝 APK 進行簽名校驗時就會不通過，從而保證了安全性。
摘要演算法： 使用一段簡單的看上去隨機的不可逆向的固定長度的字元串來表示一個文件的唯一性。 常見的摘要演算法如MD5(128個比特位)、SHA-1演算法(160/192/256個比特位)。
公鑰密碼體制：也稱非對稱演算法，特點是 公鑰是公開的 ，私鑰是保密的。常見的如：RSA。
展開討論一下RSA：

Android中的簽名方案
V1 ：基於jarsigner(JDK自帶工具，使用keystore文件進行簽名) 或 apksigner(Android專門提供的，使用pk8、x509.pem進行簽名)。keystore和pk8/x509.pem可以相互轉換。
簽名原理：首先keystore文件包含一個MD5和一個SHA1摘要。 這也是很多開放平台需要我們上傳的摘要數據 。
簽名APK後會在META-INF文件夾下生產CERT.RSA、CERT.SF、MANIFEST.MF三個文件。

在apk中，/META-INF文件夾中保存著apk的簽名信息，一般至少包含三個文件，[CERT].RSA，[CERT].SF和MANIFEIST.MF文件。這三個文件就是對apk的簽名信息。
MANIFEST.MF中包含對apk中除了/META-INF文件夾外所有文件的簽名值，簽名方法是先SHA1()(或其他hash方法)在base64()。存儲形式是：Name加[SHA1]-Digest。
[CERT].SF是對MANIFEST.MF文件整體簽名以及其中各個條目的簽名。一般地，如果是使用工具簽名，還多包括一項。就是對MANIFEST.MF頭部信息的簽名，關於這一點前面源碼分析中已經提到。
[CERT].RSA包含用私鑰對[CERT].SF的簽名以及包含公鑰信息的數字證書。
  是否存在簽名偽造可能：
修改(含增刪改)了apk中的文件，則：校驗時計算出的文件的摘要值與MANIFEST.MF文件中的條目不匹配，失敗。
修改apk中的文件+MANIFEST.MF,則：MANIFEST.MF修改過的條目的摘要與[CERT].SF對應的條目不匹配，失敗。
修改apk中的文件+MANIFEST.MF+[CERT].SF，則：計算出的[CERT].SF簽名與[CERT].RSA中記錄的簽名值不匹配，失敗。
修改apk中的文件+MANIFEST.MF+[CERT].SF+[CERT].RSA，則：由於證書不可偽造，[CERT].RSA無法偽造。

V2 ：7.0新增的
簽名後的包會被分為四部分
1. Contents of ZIP entries（from offset 0 until the start of APK Signing Block）
2. APK Signing Block
3. ZIP Central Directory
4. ZIP End of Central Directory
新應用簽名方案的簽名信息會被保存在區塊2（APK Signing Block） 中， 而區塊1（ Contents of ZIP entries ）、區塊3（ ZIP Central Directory ）、區塊4（ ZIP End of Central Directory ）是受保護的， 在簽名後任何對區塊1、3、4的修改都逃不過新的應用簽名方案的檢查 。

V3 ：9.0新增的
格式大體和 v2 類似，在 v2 插入的簽名塊（Apk Signature Block v2）中，又添加了一個新快（Attr塊） 。
在這個新塊中，會記錄我們之前的簽名信息以及新的簽名信息，以 密鑰轉輪的方案，來做簽名的替換和升級。這意味著，只要舊簽名證書在手，我們就可以通過它在新的 APK 文件中，更改簽名 。
v3 簽名新增的新塊（attr）存儲了所有的簽名信息，由更小的 Level 塊，以 鏈表 的形式存儲。
其中每個節點都包含用於為之前版本的應用簽名的簽名證書，最舊的簽名證書對應根節點，系統會讓每個節點中的證書為列表中下一個證書簽名，從而為每個新密鑰提供證據來證明它應該像舊密鑰一樣可信。
這個過程有點類似 CA 證書的證明過程，已安裝的 App 的舊簽名，確保覆蓋安裝的 APK 的新簽名正確，將信任傳遞下去。
注意： 簽名方式只支持升級不支持降級，如安裝了V2的包，不能覆蓋替換為V1的包。

參考
Android App簽名(證書)校驗過程源碼分析
新一代開源Android渠道包生成工具Walle
Android 簽名機制 v1、v2、v3