android中用的到加密：
Https編程 :應該是使用帶安全的網路協議處理。除非你本地需要加密
2.數據簽名：混淆代碼和防二次打包的APK加密技術
3.對稱加密：可以先將數據通過某種加密方式加密發送到伺服器端，然後伺服器端再解密 ，項目中除了登陸，支付等介面採用rsa非對稱加密，之外的採用aes對稱加密
4.非對稱加密====支付寶
數字摘要是指通過演算法將長數據變為短數據，通常用來標識數據的唯一性，是否被修改，常用的加密演算法有md5和sha1兩種，如Android的App簽名也是用的這兩種演算法。
由於以上兩種生成數字摘要的演算法都是不可逆的，對於可逆的加密演算法中，按照密鑰的數量和加密規則一半分為對稱加密和非對稱加密兩類：
對稱加密：
密鑰可以自己指定，只有一把密鑰，如果密鑰泄漏數據就會暴漏；
常用的對稱加密演算法有DES和AES兩種；
特點是加密速度快，但是缺點是安全性低，因為只要密鑰暴漏，數據就可以被解密。
非對稱加密的特點：
常見的非對稱加密演算法是RSA；
他有兩把密鑰，且是由程序生成的，不能自己指定；
特點是加密速度比較慢，但是安全性比較高；
加密和解密的規則是：公鑰加密只能私鑰解密，私鑰加密只能公鑰解密；
㈡ 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簽名簽名原理簡析
僅供參考，歡迎指正
㈢ APK簽名機制原理詳解
眾所周知，Android系統在安裝Apk的過程中，會對Apk進行簽名校驗，校驗通過後才能安裝成功。那你知道簽名校驗的機制是什麼？具體校驗的是什麼內容嗎？申請第三方SDK（如微信支付）時填入的SAH1值是什絕頌高么？目前眾多的快速批量打包方案又是如何繞過簽名檢驗的？
我將通過一系列的文章來解開這些疑惑：
這篇文章先來介紹Apk簽名相關的基本知識。
要知道簽名是什麼，先來看為什麼需要簽名 。大家都知道，在消息通信時，必須至少解決兩個問題：一是確保消息來源的真實性，二是確保消息不會被第三方篡改。在安裝Apk時，同樣需要確保Apk來源的真實性，以及Apk沒有被第三方篡改。如何解決這兩個問題呢？方法就是開發者對Apk進行簽名：在Apk中寫入一個「指紋」。指紋寫入以後，Apk中有任何修改，都會導致這個指紋無效，Android系統在安裝Apk進行簽名校驗時就會不通過，從而保證了安全性。
要了解如何實現簽名，需要了解兩個基本概念：數字摘要和數字證書。
簡單來說，就是對一個任意長度的數據，通過一個Hash演算法計算後，都可以得到一個固定長度的二進制數據，這個數據就稱為「摘要」。摘要具有下面的幾個特徵：
前面已經說到，可以通過簽名來確保數據來源的可靠性和數據的不可篡改性。簽名就是在摘要的基礎上再進行一次加密，對摘要加密後的數據就可以當作數字簽名，在安裝Apk需要對簽名進行驗證，驗證通過才能繼續安裝。
這里有兩個過程：簽名過程 和 校驗過程。
先來說 簽名過程：
再來看 校驗過程：
這里有一個前提：接收方必須要知道發送方的公鑰和所使用的演算法。如果數字簽名和公鑰一起被篡改，接收方無法得知，還是會校驗通過。如何保證公鑰的可靠性呢？答案是數字證書，數字證書是身份認證機構（Certificate Authority）頒發的，包含了以下信息：
接收方收到消息後，先向CA驗證證書的合法性（根據證書的簽名、綁定的域名等信息。CA機構是權威的，可以保證這個過程的可靠性。）再進行簽名校驗。
需要注意的是，Apk的證書通常的自簽名的，也就是由開發者自己製作，沒有向CA機構申請。Android在安裝Apk時並沒有校驗證書本身的合法性，只是從證書中提取公鑰和加密演算法，這也正是對第三方Apk重新簽名後，還能夠繼續在沒有安裝這個Apk的系統中繼續安裝的原因。
我們在對Apk簽名時並沒有直接指定私鑰、公鑰和數字證書，而是使用keystore文件，這些信息都包含在了keystore文件中。根據編碼不同，keystore文件分為很多種，Android使用的是Java標准keystore格式JKS(Java Key Storage)，所以通過Android Studio導出的keystore文件是以.jks結尾的。
keystore使用的證書標準是X.509，X.509標准也有多種編碼格式，常用的有兩種：pem（Privacy Enhanced Mail）和der（Distinguished Encoding Rules）。jks使用的是der格式，Android也支持直接使用pem格式的證書進行簽名，我們下面會介紹。
兩種證書編碼格式的區別：
X.509證書格式：
Android提供了兩種對Apk的簽名方式，一種是基於JAR的簽名方式，另一種是基於Apk的簽名方式，它們的主要區別在於使用的簽名文件不一樣：jarsigner使用keystore文件進行簽名；apksigner除了並尺支持使用keystore文件進行簽名外，還支持直接指定pem證書文件和私鑰進行簽名。
不知道大家有沒有注意一個問題，我們通過櫻御keytool或者AS生成一個keystore的時候（ 簽署您的應用 ），除了要輸入keystore的密碼外，還要輸入一個alias和key的密碼。在簽名時，除了要指定keystore文件和密碼外，也要指定alias和key的密碼，這是為什麼呢？
原因是keystore是一個密鑰庫，也就是說它可以存儲多對密鑰和證書，keystore的密碼是用於保護keystore本身的，一對密鑰和證書是通過alias來區分的。從這里可以看出jarsigner是支持使用多個證書對Apk進行簽名的。apksigner也同樣支持，關於apksigner的使用介紹可以參考官方文檔 apksigner 。
ok，簽名的基本概念和校驗過程就介紹到這里，關於JAR簽名和V2簽名機制的詳細介紹，參考下面兩篇文章：
㈣ 一文弄懂關於證書，簽名，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中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 | 他山之石，可以攻玉！一篇文章看懂 v1/v2/v3 簽名機制
這篇文章的內容會涉及以下前置 / 相關知識，貼心的我都幫你准備好了，請享用~
數字簽名（Digital Signature）也叫作數字指紋（Digital Fingerprint），它是消息摘要演算法和非對稱加密演算法的結合體，能夠驗證數據的完整性，並且認證數據的來源 。
數據簽名演算法的模型分為兩個主要階段：
需要注意的是，Android 目前不對應用證書進行 CA 認證，應用可以由第三方（OEM、運營商、其他應用市場）簽名，也可以自行簽名。
應用 APK 其實是一種特殊的 Zip 壓縮包，無法避免惡意破解者解壓 / 反編譯修改內容，針對這個問題有何解決方案呢？他山之石，可以攻玉 ——數字簽名演算法。應用簽名正是數字簽名演算法的應用場景之一，與其他應用場景類似，目的無非是：
Android 平台上運行的每個應用都必須有開發者的簽名。在慧喚安裝應用時，軟體包管理器會驗證 APK 是否已經過適當簽名，安裝程序會拒絕沒有獲得簽名就嘗試安裝的應用。
軟體包管理器在安裝應用前會驗證應用摘要，如果破解者修改了 apk 里的內容，那麼摘要就不再匹配，驗證失敗（驗證流程見下文方案）。
截止至 Android 11，Android 支持以下三種應用簽名方案：
為了提高兼容性，必須按照 v1、v2、v3 的先後順序採用簽名方案，低版本平台會忽略高版本的簽名方案在 APK 中添加的額外數據。
v1 簽名方案是基於 Jar 的簽名。
首先，我們先來分析其簽名產物。 v1 簽名後會增加 META-INF 文件夾 ，其中會有如下三個文件。考慮到使用不同的證書和簽名方式，得到的文件名可能不同，因此你只要留意文件的後綴即可：
v1 簽名流程如下：
MANIFEST.MF（Message Digest File，摘要文件）
*.SF（Signature File，簽名文件）
驗證流程可以分為驗證簽名和驗證完整性兩個步驟：
驗證簽名步驟：
如果上述簽名驗證結果正確，才會驗證完整性：
以上任何步驟驗證失敗，則整個 APK 驗證失敗。
為了解決這些問題，Android 7.0 中引入了 APK 簽名方案 v2。
v2 簽名方案是一種 全文件簽名方案 ，該方案能夠發現對 APK 的受保護部分進行的所有更改，相對於 v1 簽名方案驗證速度更快，完整性覆蓋范圍更廣。
在分析 v2 簽名方案之前，我們先簡單了解一下 Zip 文件格式：
首先，我們先來分析其簽名產物。v2 簽名後會在 「條目內容區」和「中央目錄區」之間插入「APK 簽名分塊（APK Signing Block）」 。
從左到右邊，我們定義為區塊 1~4。
相對與 v1 簽名方案，v2 簽名方案不再以文件為單位計算摘要了，而敬坦是以 1 MB 為單位將文件拆分為多個連續的塊（chunk），每個分區的最後一個塊可能會小於 1 MB。
v2 簽亮碧桐名流程如下：
驗證流程可以分為驗證簽名和驗證完整性兩個步驟：
簽名方案 v3 支持密鑰輪換，應用能夠在 APK 更新過程中更改其簽名密鑰。
【累了，後面先不寫了...】
這一節，我們介紹基於 Android 應用簽名機制的衍生應用場景。
在 v1 方案中， MANIFEST.MF 和 *.SF 這兩個文件會記錄大量的文件名和文件摘要。如果 apk 中文件數很多，而且文件名很長，那麼這兩個文件會變得很大。使用 AndResGuard 工具，可以將文件名轉換為短路徑文件名，從而減少這兩個文件的大小。
在實際生產中，往往需要生成多個渠道的 APK 包，傳統的方法是使用 APKTool 逆向工具、Flavor + BuildType 等方案，這一類多渠道打包方案的缺點是耗時嚴重。隨著 Android 應用簽名方案的演進，演變出了不同的多渠道打包方案：
在 v1 方案中，我們提到了完整性校驗不覆蓋到 META-INF 文件夾的問題。有些多渠道打包方案就是利用了這個問題，在 META-INF 文件夾下添加空文件， 用空文件的名稱來作為渠道的唯一標識 ，就可以節省打包的時間，提高打渠道包的速度。
除了添加空文件的方法，還可以向 APK 添加 Zip Comment 來生成多渠道包（APK 本身就是特殊的 Zip 包）。
在 v2 簽名方案中，幾乎整個 APK 都納入保護范圍，如果向 APK 添加空文件或 Zip Comment 的話，在安裝時會報以下錯誤：
新背景下的多渠道打包方案，則是利用了 APK 簽名分塊（區塊 2）不受保護 & 欄位可擴展的特點 ，向區塊中添加多渠道信息（ID-Value），例如 美團多渠道打包方案 Walle 。