android數(shù)字簽名,android 電子簽名

Android V1及V2簽名原理簡(jiǎn)析

Android為了保證系統(tǒng)及應(yīng)用的安全性，在安裝APK的時(shí)候需要校驗(yàn)包的完整性，同時(shí)，對(duì)于覆蓋安裝的場(chǎng)景還要校驗(yàn)新舊是否匹配，這兩者都是通過Android簽名機(jī)制來進(jìn)行保證的，本文就簡(jiǎn)單看下Android的簽名與校驗(yàn)原理，分一下幾個(gè)部分分析下：

肅南裕固族自治網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營(yíng)維護(hù)。成都創(chuàng)新互聯(lián)自2013年創(chuàng)立以來到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)。

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

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

同時(shí)具有V1 V2簽名：

可以看到，如果只有V2簽名，那么APK包內(nèi)容幾乎是沒有改動(dòng)的，META_INF中不會(huì)有新增文件，按Google官方文檔：在使用v2簽名方案進(jìn)行簽名時(shí)，會(huì)在APK文件中插入一個(gè)APK簽名分塊，該分塊位于zip中央目錄部分之前并緊鄰該部分。在APK簽名分塊內(nèi)， 簽名和簽名者身份信息會(huì)存儲(chǔ)在APK簽名方案v2分塊中，保證整個(gè)APK文件不可修改 ，如下圖：

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

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

如果對(duì)APK中的資源文件進(jìn)行了替換，那么該資源的摘要必定發(fā)生改變，如果沒有修改MANIFEST.MF中的信息，那么在安裝時(shí)候V1校驗(yàn)就會(huì)失敗，無法安裝，不過如果篡改文件的同時(shí)，也修改其MANIFEST.MF中的摘要值，那么MANIFEST.MF校驗(yàn)就可以繞過。

CERT.SF個(gè)人覺得有點(diǎn)像冗余，更像對(duì)文件完整性的二次保證，同繞過MANIFEST.MF一樣，.SF校驗(yàn)也很容易被繞過。

CERT.RSA與CERT.SF是相互對(duì)應(yīng)的，兩者名字前綴必須一致，不知道算不算一個(gè)無聊的標(biāo)準(zhǔn)?？聪翪ERT.RSA文件內(nèi)容：

CERT.RSA文件里面存儲(chǔ)了證書公鑰、過期日期、發(fā)行人、加密算法等信息，根據(jù)公鑰及加密算法，Android系統(tǒng)就能計(jì)算出CERT.SF的摘要信息，其嚴(yán)格的格式如下：

從CERT.RSA中，我們能獲的證書的指紋信息，在微信分享、第三方SDK申請(qǐng)的時(shí)候經(jīng)常用到，其實(shí)就是公鑰+開發(fā)者信息的一個(gè)簽名：

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

前面說過V1簽名中文件的完整性很容易被繞過，可以理解 單個(gè)文件完整性校驗(yàn)的意義并不是很大 ，安裝的時(shí)候反而耗時(shí)，不如采用更加簡(jiǎn)單的便捷的校驗(yàn)方式。V2簽名就不針對(duì)單個(gè)文件校驗(yàn)了，而是 針對(duì)APK進(jìn)行校驗(yàn) ，將APK分成1M的塊，對(duì)每個(gè)塊計(jì)算值摘要，之后針對(duì)所有摘要進(jìn)行摘要，再利用摘要進(jìn)行簽名。

也就是說，V2摘要簽名分兩級(jí)，第一級(jí)是對(duì)APK文件的1、3 、4 部分進(jìn)行摘要，第二級(jí)是對(duì)第一級(jí)的摘要集合進(jìn)行摘要，然后利用秘鑰進(jìn)行簽名。安裝的時(shí)候，塊摘要可以并行處理，這樣可以提高校驗(yàn)速度。

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

而數(shù)字簽名是什么呢（公鑰數(shù)字簽名），利用非對(duì)稱加密技術(shù)，通過私鑰對(duì)摘要進(jìn)行加密，產(chǎn)生一個(gè)字符串，這個(gè)字符串+公鑰證書就可以看做消息的數(shù)字簽名，如RSA就是常用的非對(duì)稱加密算法。在沒有私鑰的前提下，非對(duì)稱加密算法能確保別人無法偽造簽名，因此數(shù)字簽名也是對(duì)發(fā)送者信息真實(shí)性的一個(gè)有效證明。不過由于Android的keystore證書是自簽名的，沒有第三方權(quán)威機(jī)構(gòu)認(rèn)證，用戶可以自行生成keystore，Android簽名方案無法保證APK不被二次簽名。

知道了摘要跟簽名的概念后，再來看看Android的簽名文件怎么來的？如何影響原來APK包？通過sdk中的apksign來對(duì)一個(gè)APK進(jìn)行簽名的命令如下：

其主要實(shí)現(xiàn)在 android/platform/tools/apksig 文件夾中，主體是ApkSigner.java的sign函數(shù)，函數(shù)比較長(zhǎng)，分幾步分析

先來看這一步，ApkUtils.findZipSections，這個(gè)函數(shù)主要是解析APK文件，獲得ZIP格式的一些簡(jiǎn)單信息，并返回一個(gè)ZipSections，

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

獲取到 ZipSections之后，就可以進(jìn)一步解析APK這個(gè)ZIP包，繼續(xù)走后面的簽名流程，

可以看到先進(jìn)行了一個(gè)V2簽名的檢驗(yàn)，這里是用來簽名，為什么先檢驗(yàn)了一次？第一次簽名的時(shí)候會(huì)直接走這個(gè)異常邏輯分支，重復(fù)簽名的時(shí)候才能獲到取之前的V2簽名，懷疑這里獲取V2簽名的目的應(yīng)該是為了排除V2簽名，并獲取V2簽名以外的數(shù)據(jù)塊，因?yàn)楹灻旧聿荒鼙凰闳氲胶灻?，之后?huì)解析中央目錄區(qū)，構(gòu)建一個(gè)DefaultApkSignerEngine用于簽名

先解析中央目錄區(qū)，獲取AndroidManifest文件，獲取minSdkVersion(影響簽名算法)，并構(gòu)建DefaultApkSignerEngine，默認(rèn)情況下V1 V2簽名都是打開的。

第五步與第六步的主要工作是：apk的預(yù)處理，包括目錄的一些排序之類的工作，應(yīng)該是為了更高效處理簽名，預(yù)處理結(jié)束后，就開始簽名流程，首先做的是V1簽名（默認(rèn)存在，除非主動(dòng)關(guān)閉）：

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

這里特殊提一下重復(fù)簽名的問題： 對(duì)一個(gè)已經(jīng)V1簽名的APK再次V1簽名不會(huì)有任何問題 ，原理就是：再次簽名的時(shí)候，會(huì)排除之前的簽名文件。

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

V2SchemeSigner處理V2簽名，邏輯比較清晰，直接對(duì)V1簽名過的APK進(jìn)行分塊摘要，再集合簽名，V2簽名不會(huì)改變之前V1簽名后的任何信息，簽名后，在中央目錄前添加V2簽名塊，并更新中央目錄結(jié)尾信息，因?yàn)閂2簽名后，中央目錄的偏移會(huì)再次改變：

簽名校驗(yàn)的過程可以看做簽名的逆向，只不過覆蓋安裝可能還要校驗(yàn)公鑰及證書信息一致，否則覆蓋安裝會(huì)失敗。簽名校驗(yàn)的入口在PackageManagerService的install里，安裝官方文檔，7.0以上的手機(jī)優(yōu)先檢測(cè)V2簽名，如果V2簽名不存在，再校驗(yàn)V1簽名，對(duì)于7.0以下的手機(jī)，不存在V2簽名校驗(yàn)機(jī)制，只會(huì)校驗(yàn)V1，所以，如果你的App的miniSdkVersion24(N)，那么你的簽名方式必須內(nèi)含V1簽名：

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

這里只關(guān)心證書部分：

Android V1及V2簽名簽名原理簡(jiǎn)析

僅供參考，歡迎指正

Android簽名有什么作用

所有的Android應(yīng)用程序都要求開發(fā)人員用一個(gè)證書進(jìn)行數(shù)字簽名，Android系統(tǒng)不會(huì)安裝沒有進(jìn)行簽名的應(yīng)用程序。 平時(shí)我們的程序可以在模擬器上安裝并運(yùn)行，是因?yàn)樵趹?yīng)用程序開發(fā)期間，由于是以Debug面試進(jìn)行編譯的，因此ADT根據(jù)會(huì)自動(dòng)用默認(rèn)的密鑰和證書來進(jìn)行簽名，而在以發(fā)布模式編譯時(shí)，apk文件就不會(huì)得到自動(dòng)簽名，這樣就需要進(jìn)行手工簽名。給apk簽名可以帶來以下好處:1.、應(yīng)用程序升級(jí):如果你希望用戶無縫升級(jí)到新的版本，那么你必須用同一個(gè)證書進(jìn)行簽名。這是由于只有以同一個(gè)證書簽名，系統(tǒng)才會(huì)允許安裝升級(jí)的應(yīng)用程序。如果你采用了不同的證書，那么系統(tǒng)會(huì)要求你的應(yīng)用程序采用不同的包名稱，在這種情況下相當(dāng)于安裝了一個(gè)全新的應(yīng)用程序。如果想升級(jí)應(yīng)用程序，簽名證書要相同，包名稱要相同!2、應(yīng)用程序模塊化:Android系統(tǒng)可以允許同一個(gè)證書簽名的多個(gè)應(yīng)用程序在一個(gè)進(jìn)程里運(yùn)行，系統(tǒng)實(shí)際把他們作為一個(gè)單個(gè)的應(yīng)用程序，此時(shí)就可以把我們的應(yīng)用程序以模塊的方式進(jìn)行部署，而用戶可以獨(dú)立的升級(jí)其中的一個(gè)模塊3、代碼或者數(shù)據(jù)共享:Android提供了基于簽名的權(quán)限機(jī)制，那么一個(gè)應(yīng)用程序就可以為另一個(gè)以相同證書簽名的應(yīng)用程序公開自己的功能。以同一個(gè)證書對(duì)多個(gè)應(yīng)用程序進(jìn)行簽名，利用基于簽名的權(quán)限檢查，你就可以在應(yīng)用程序間以安全的方式共享代碼和數(shù)據(jù)了。不同的應(yīng)用程序之間，想共享數(shù)據(jù)，或者共享代碼，那么要讓他們運(yùn)行在同一個(gè)進(jìn)程中，而且要讓他們用相同的證書簽名。

Android的數(shù)字簽名

要確?？煽客ㄐ?，要解決兩個(gè)問題：第一，要確定消息的來源確實(shí)是其申明的那個(gè)人；其次，要保證信息在傳遞的過程中不被第三方篡改，即使被篡改了，也可以發(fā)覺出來。

數(shù)字簽名，就是為了解決這兩個(gè)問題而產(chǎn)生的，它是對(duì)前面提到的非對(duì)稱加密技術(shù)與數(shù)字摘要技術(shù)的一個(gè)具體的應(yīng)用。

對(duì)于消息的發(fā)送者來說，先要生成一對(duì)公私鑰對(duì)，將公鑰給消息的接收者。

如果消息的發(fā)送者有一天想給消息接收者發(fā)消息，在發(fā)送的信息中，除了要包含原始的消息外，還要加上另外一段消息。這段消息通過如下兩步生成：

1）對(duì)要發(fā)送的原始消息提取消息摘要；

2）對(duì)提取的信息摘要用自己的私鑰加密。

通過這兩步得出的消息，就是所謂的原始信息的數(shù)字簽名。

而對(duì)于信息的接收者來說，他所收到的信息，將包含兩個(gè)部分，一是原始的消息內(nèi)容，二是附加的那段數(shù)字簽名。他將通過以下三步來驗(yàn)證消息的真?zhèn)危?/p>

1）對(duì)原始消息部分提取消息摘要，注意這里使用的消息摘要算法要和發(fā)送方使用的一致；

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

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

通過這種數(shù)字簽名技術(shù)，確實(shí)可以有效解決可靠通信的問題。如果原始消息在傳送的過程中被篡改了，那么在消息接收者那里，對(duì)被篡改的消息提取的摘要肯定和原始的不一樣。并且，由于篡改者沒有消息發(fā)送方的私鑰，即使他可以重新算出被篡改消息的摘要，也不能偽造出數(shù)字簽名。

綜上所述，數(shù)字簽名其實(shí)就是只有信息的發(fā)送者才能產(chǎn)生的別人無法偽造的一段數(shù)字串，這段數(shù)字串同時(shí)也是對(duì)信息的發(fā)送者發(fā)送信息真實(shí)性的一個(gè)有效證明。

很多時(shí)候根本就不具備事先溝通公鑰的信息通道。那么如何保證公鑰的安全可信呢？這就要靠數(shù)字證書來解決了。

所謂數(shù)字證書，一般包含以下一些內(nèi)容：

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

證書的有效期（Validity）

消息發(fā)送方的公鑰

證書所有者（Subject）

·? ?指紋以及指紋算法

數(shù)字簽名

解壓 Android簽名apk之后，會(huì)有一個(gè)META-INF文件夾，這里有三個(gè)文件：

MANIFEST.MF

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

CERT.SF

1》計(jì)算這個(gè)MANIFEST.MF文件的整體SHA1值，再經(jīng)過BASE64編碼后，記錄在CERT.SF主屬性塊（在文件頭上）的“SHA1-Digest-Manifest”屬性值值下

2》逐條計(jì)算MANIFEST.MF文件中每一個(gè)塊的SHA1，并經(jīng)過BASE64編碼后，記錄在CERT.SF中的同名塊中，屬性的名字是“SHA1-Digest

CERT.RSA

會(huì)把之前生成的 CERT.SF文件， 用私鑰計(jì)算出簽名, 然后將簽名以及包含公鑰信息的數(shù)字證書一同寫入 ?CERT.RSA ?中保存。CERT.RSA是一個(gè)滿足PKCS7格式的文件。

如果你改變了apk包中的任何文件，那么在apk安裝校驗(yàn)時(shí)，改變后的文件摘要信息與MANIFEST.MF的檢驗(yàn)信息不同，于是驗(yàn)證失敗，程序就不能成功安裝。

其次，如果你對(duì)更改的過的文件相應(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)闆]有數(shù)字證書對(duì)應(yīng)的私鑰。

所以，如果要重新打包后的應(yīng)用程序能再Android設(shè)備上安裝，必須對(duì)其進(jìn)行重簽名。

新聞名稱：android數(shù)字簽名,android 電子簽名
本文地址：http://muchs.cn/article10/phgigo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、企業(yè)建站、網(wǎng)站制作、響應(yīng)式網(wǎng)站、微信公眾號(hào)、外貿(mào)網(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)