做IOS開發也有兩年了，記得第一次接觸IOS時，碰到的第一個問題就是這個證書，稀里糊涂的把攔路的問題搞定后，也沒有進一步的去深入的探究下這個到底是什么東西，為什么要這樣。

1.對稱加密

對稱加密是密碼學中一類加密算法的統稱，這類算法在加密與解密時使用相同的密鑰，或者使用兩個可以簡單的相互推算的密鑰。常見的對稱加密算法有DES、3DES、AES、RC5等。相比非對稱加密算法，對稱加密算法的優點是加解密的速度很快。

2.非對稱加密

非對稱加密是指加密密鑰與解密密鑰是成對出現的，其中一個對外公開，叫公鑰，另一個末公開的叫私鑰，幾乎不能從一個密鑰計算出另一個密鑰。通過私鑰加密的只能通過公鑰解密，公鑰加密的只能通過私鑰解密。最著名的非對稱加密算法是RSA算法。當然如此強大可靠的安全性是在犧牲加密速度的基礎上得到的。

3.摘要算法

摘要算法可以將任意長度的信息（文本、字節等）通過算法轉換成一個固定長度的文本。只要源信息不同，摘要算法得到的結果必然不同。且無法從摘要算法的結果反推得到源信息。比較典型的摘要算法有MD5與SHA等。

4.數字簽名

數字簽名實際上是非對稱加密算法與摘要算法的結合。將要發布的源信息通過摘要算法得到摘要，再將得到的摘要通過非對稱加密算法中的密鑰進行加密，最后將源信息、加密后的摘要密文與解密公鑰打包到一塊發布。

接收方接收到信息后需要先通過公鑰從摘要密文中解析出原摘要信息，然后通過摘要算法從源信息明文中再次計算出摘要信息，最后將兩個接要進行比對，相等就認為一切正常。完整的流程見下圖：

5.數字證書

數字證書就是通過數字簽名實現的數字化證書。蘋果的開發者證書就是這種東東，證書的簽發機構（Certificate Authority）自然是Apple，證書的被簽發人是企業（企業證書）或者個人開發者（個人開發證書），證書的驗證方是IOS設備，IOS系統已經將整個驗證流程固化到系統中，除非越獄，否則無法繞過。

接下來我們正式開始來了解IOS這個東西。還記得我們是如何向蘋果申請證書的嗎？不記得了得話Google下吧，一個步驟一個步驟說的非常詳細。

CertificateSigningRequest.certSigningRequest

申請證書過程中蘋果會要求我們從MAC電腦上上傳一個后綴名為certSigningRequest的文件，見下圖。

我們可以嘗試通過openssl來查看下這個文件的內容，如下圖：

可以看到這個文件大致包括三個方面的內容：申請者的相關信息、申請者的公鑰、接要算法與公鑰加密算法。

開發證書與生產證書

實際上蘋果只關心這個文件中的公鑰信息，它將這個公鑰封裝在將要分發給開發者的證書中，并進行數字簽名，我們同樣可以用openssl來查看證書的內容：

從上圖簽名內容的Data域中我們可以看到簽名證書的相關信息，其中最重要的東西就是簽名證書的公鑰了。雙擊這個證書，MAC會自動將該證書導入到鑰匙串應用中，與些同時MAC還會將本機對應的鑰匙與這個證書中的公鑰對應起來，因此我們在Keychain中查看證書時，可以看到證書自動的關聯了私鑰，如下圖：

也正因為如此，在使用多臺MAC開發機器的團隊開發過程中，一般都是由一臺機器申請證書后，再將證書與私鑰同時導出共享給其它開發成員使用，導出截圖如下圖：

開發證書與發布證書有什么區別呢？這兩種證書只是在用途上有所不同，開發證書用于開發調試應用，生產證書用于正式發布應用。本質上來說，只要這兩個證書是使用同一個certSigningRequest文件生成的，他們都擁有著相同的私鑰與公鑰。

mobileprovision

在我們平常開發過程中除了與證書打交道外，還會碰到一個后綴為mobileprovision的文件，這個又是什么鬼呢？這個東西的中文名叫做IOS授權與描述文件。我們可以使用下面的命令來查看該文件的內容：

可以猜測到該文件主要包括這樣幾個方面的內容：App的相關信息（AppId、創建時間、面向平臺等）、App所使用到的功能授權列表（正因為這個原因，我們把它稱為授權與描述文件）、可以使用這個授權文件的證書列表（DeveloperCertificates這一項，使用了Base64編碼，我嘗試解碼，也只是看到了一部分可讀數據，還是有一部分的亂碼文件，http://objccn.io/issue-17-2/這篇文章中說可以使用openssl x509 -text -in file.pem命令來解碼，但我沒有嘗試成功）、可安裝的設備列表（每次我們使用新的設備時，都必須先將設備UID添加到后臺的設備列表中，然后重新更新該mobileprovision文件，幸運的是XCODE能夠默默的為我們做到這一切，該配置只適用于開發證書）、蘋果自己的簽名（與上面的公鑰、私鑰沒有關系，蘋果用來驗證mobileprovision文件自身的合法性）。

IPA簽名與解密

xcode在打包過程中會調用系統中的codesign命令使用賬號中的私鑰對應用的所有文件進行簽名，并保存在ipa中的_CodeSignature文件夾下。

當App安裝后，系統首先找到ipa包中的embedded.mobileprovision文件，驗證這個文件自身的合法性，然后再通過該文件找到證書，再通過證書獲取到解密用的公鑰，解密所有經過數字簽名的文件，并比較摘要是否一致。如果這些環節中的一個有問題，整個驗證工作就宣告失敗。

整個簽名與解密的流程寫的比較簡略，只有一個大概的流程，究其原因還是網上很多資料對這一塊言之過少，大都三言兩語一帶而過，希望后續自己能對其進行更進一步的補充。大致流程參見下圖：

下面這些關于ipa簽名的結論是我自己的猜測，不一定準確：

1．對于ipa包中的所有文件來說，蘋果同樣會獲取這些文件的摘要信息，但隨ipa包一塊發布的卻是這些文件的明文，這也是為什么我們將ipa解壓后能直接讀取info.plist等文件內容的原因。

3．對于所有獲取的摘要信息，同樣都使用私鑰再次加密后保存在_CodeSignature文件夾下的CodeResources文件中。

4.蘋果獲取這些文件后，會對IPA包中的代碼文件進行再一次的加密（用戶從appstore上下載的ipa包文件中的可執行文件，使用class_dump無法正確的獲取頭文件，必須要使用手機執行應用，然后通過內存中的信息獲取解密后的可執行文件），至于這上次的加密是否用開發者的私鑰，這個我不太清楚。

4．解密時通過公鑰還原摘要信息，然后根據不同的文件類型采用不同的方式獲取最終的摘要信息，最后兩相比較，確定文件是否發生過變更。

文／秦磚（簡書作者）

原文鏈接：www.lxweimin.com/p/19aaa3586826

著作權歸作者所有，轉載請聯系作者獲得授權，并標注“簡書作者”。