公鑰、私鑰、數字證書和Android簽名

公鑰和私鑰

一、傳統加密的痛點
說起公鑰和私鑰，就要從信息加密的痛點說起。

小明給jack發消息，爲了防止被別人竊聽、篡改，需要對內容加密。所以他們兩約定了一種加密算法X，小明通過加密算法X對消息加密，jack收到消息後通過加密算法X對內容解密。

問題又來了，這種情況需要小明提前把加密算法X發給jack，加密算法有可能被竊聽，這樣黑客還是能對消息進行竊聽、篡改。

二、公鑰、私鑰的特點
後來就有人發明了公鑰、私鑰來解決這個問題，公鑰、私鑰具有如下特點：

從上述特點大致可以看出，使用接收方的公鑰加密消息，只有接收方的私鑰才能解密，而私鑰是不會公開的，所以黑客沒有機會竊聽了。

三、公、私鑰是如何解決上面的兩個問題的
那麼再回到剛纔的痛點，通過下面的方法就能解決：

jack把自己的公鑰發送給小明、小明把自己的公鑰發送給jack。這個過程被黑客截取到了也沒關係；
小明提取出消息正文的MD5碼，然後使用自己的私鑰加密MD5碼，得到文件稱爲數字簽名。簽名是什麼意思？因爲這個文件是小明的私鑰加密的，只有小明的公鑰才能解密，反過來說，如果使用小明的公鑰解密出來了，就說明這個文件一定是小明的私鑰加密的，就證明了消息的發送者是小明；
小明通過jack的公鑰對消息正文加密，得到加密消息；
小明把數字簽名、加密消息一起發送給jack；

jack接收到消息後需要判斷兩點：消息是否正確完整、消息是否是小明發送的。

jack使用小明的公鑰解密數字簽名，得到MD5碼，如果能正確解密就說明發送人是小明。然後再用自己的私鑰對加密消息進行解密，並提取出消息正文的MD5碼，和上一步得到的MD5碼對比，如果一致，就說明消息是正確完整的。

整個過程，黑客只有兩個人的公鑰，只能解析出數字簽名解析出MD5碼，真正的內容無法解密。如果對消息內容進行損壞，jack也能發現。

其實上面的過程還是有一個漏洞：小明把公鑰發送給jack的時候，黑客可以截取公鑰，然後把黑客自己的公鑰發送給jack，這樣就會導致小明、jack永遠在跟中間人通信。

所以這裏就涉及到一個問題：公鑰如何準確無誤地發放？

這裏就要引入權威的證書授權機構——CA，小明去CA機構申請證書，將小明的個人信息、公鑰生成一個證書，然後把這個證書發送給jack，jack拿這個證書去證書授權機構查詢，如果能匹配上小明的信息，就說明這個證書是小明的，就可以使用證書中的公鑰來解密小明的消息。

通過公鑰、私鑰和數字證書，就形成了一套完美的消息加密機制。

Android簽名主要有兩種方式，一種是通過keystore，一種是通過.pk8和x509.pem，這兩種方式是可以轉換的，總之最終的目的就是通過私鑰和公鑰對apk進行簽名。注意，它叫“簽名”，不叫“加密”，至於爲什麼，後面會講到。

下面先簡單介紹下兩種簽名方式。

一、通過keystore簽名
第一步，使用keytool生成keysotre文件。keystore文件中包含了我們的私鑰和公鑰。

superwk是別名，36500天是使用時間，F:\SingnTest\wk.keystore是最終文件

第二步，使用剛纔生成的keystore文件對app進行簽名。

上面的4個參數分別是：keystore文件、簽名完成後的apk、待簽名的apk、kestore的別名

二、通過.pk8和x509.pem簽名
第一步，獲取.pk8和x509.pem文件。可以通過keystore文件轉換得到，具體可以百度。

第二步，使用signapk.jar工具進行簽名：

可以看出，使用keystore簽名時，需要輸入私人密碼、別名，一般是自己進行簽名時纔會使用這種方法。如果有需要讓別人簽名，就不適合用keystore了（需要告訴別人密碼），這時可以生成pk8和x509.pem文件發給他進行簽名。

結合上面消息加密的例子，Android簽名中，開發者小剛就是發送方，apk就是消息，keystore就是發送者的私鑰、公鑰，我們的apk是發送給Android手機（Android系統）進行安裝，所以Android安裝系統就是接收方。

Android系統收到apk後會做兩件事：

通過這兩步，就能保證apk升級版本時，不會被黑客修改內容，也不會被惡意程序覆蓋安裝。

但是這個過程有兩個小問題：

開發者小剛沒有Android系統的公鑰對內容進行加密，無法防止第三方竊聽消息內容，所以需要對app進行加固、代碼混淆；
開發者小剛沒有在權威授權機構申請證書，Android系統無法判斷髮送者是否是開發者小剛，只能判斷新舊apk是否是同一個開發者。不過，Android簽名的目的只是防止被惡意覆蓋，並沒有說要保證開發者是否是某個固定的人或公司。