理解iOS簽名原理

在網絡中，咱們經過對信息進行數字簽名，來驗證信息的真實性、完整性。若是將數字簽名運用到代碼中，即對可執行文件(Mach-O)或腳本(代碼)進行數字簽名，即可保證app在簽名後不被修改或損壞，保護app代碼的完整性和安全性，這就是 代碼簽名。基於代碼簽名的這個特色，幾乎全部的軟件公司在發佈app時都會對其進行代碼簽名，蘋果公司也不例外。蘋果的app簽名機制能確保安裝到用戶蘋果設備（如iPhone、iPad等）上的app都是通過蘋果官方容許的。接下來，咱們來詳細介紹一下iOS簽名原理。

數字簽名是 非對稱加密技術 與 數字摘要技術（Hash） 的應用。

1. 名詞介紹

先了解幾個iOS簽名相關的名詞

1.1 App ID

App ID用於標識一個或者一組App。主要有兩種：

• Explicit App ID：是app的惟一標識符，它由蘋果爲開發者建立的team id和app的bundle id組成。每一個app都會有且僅有一個明確的Explicit App ID。
• Wildcard App ID：即通配符App ID，用於標識一組app，以*結束，如com.company.*標識以com.company開頭的全部應用程序。

1.2 Certificate（即證書）

Certificate是用來給應用程序簽名的，只有通過簽名的應用程序才能保證他的來源是可信任的，而且代碼是完整的、未經修改的。證書的後綴爲.cer

在咱們申請證書前，須要先申請一個CSR（即Certificate Signing Request）文件，此過程其實是生成一對密鑰（即公鑰和私鑰），這對密鑰將保存在開發者Mac電腦的Keychain（即鑰匙串訪問）中，CSR文件中則包含公鑰。

證書類型有不少種，這裏簡單介紹一下常見的：

• iOS App Development（即開發證書），用於開發和真機調試app
• iOS Distribution (App Store and Ad Hoc)（即分發證書），用於蘋果應用市場（App Store）和內部分發渠道（Ad Hoc）
• APNS（Apple Push Notification Service，即蘋果推送證書），用於推送通知到app。
  • 與開發證書和分發證書不一樣的是，APNS與App ID有關。
  • APNS有兩種證書，分別是用於開發環境的 iOS Apple Push Notification service SSL (Sandbox)，以及用於生產環境的 Apple Push Notification service SSL (Sandbox & Production)。若是你的app有推送服務，這兩種推送證書都是須要建立的。

1.3 p12文件

也叫作p12證書，由於其自己就是一個加密的證書，後綴爲.p12。開發者將CSR文件發給蘋果服務器，由此蘋果服務器會生成Certificate文件（含公鑰），接着開發者將其下載到本地，再導入鑰匙串中後，就能夠從鑰匙串中導出p12證書。顯然，p12文件裏面有匹配的公鑰和私鑰。

注意：p12文件通常是給開發團隊的其餘人使用的。當別人拿到p12文件和描述文件（後面會講到），輸入正確的密碼後，就能夠將p12導入到他的Mac設備的鑰匙串中，而後再雙擊描述文件，便可添加到XCode中，從而參與團隊開發。

1.4 Device（即設備）

Devices中包含了蘋果開發者帳號中全部可用於開發和測試的設備，每臺設備使用UDID來惟一標識。在蘋果開發者帳戶每一年的會員期內，你能爲每一個產品添加最多100 個設備。

獲取UDID的方法有不少種，做者經常使用的是在iPhone的Safari瀏覽器中打開 fir.im/udid 網站便可獲取設備的UDID。

1.5 Provisioning Profile（即描述文件）

一個描述文件包含了App ID、Certificate、Device，其後綴爲.mobileprovision。經常使用的有：

• iOS App Development，用於開發時的真機調試，包含App ID、證書和設備
• Ad Hoc，用於分發時的真機調試，一樣包含App ID、證書和設備
• App Store，用於分發到蘋果應用市場，包含App ID和證書，與設備無關，且全部能訪問App Store的蘋果設備都可下載安裝app。

描述文件的做用主要是：

• 限制只有在蘋果後臺註冊過的設備才能夠安裝
• 限制簽名只能針對某一個具體的App

描述文件中還包含Entitlements（權限信息），權限信息指明瞭app使用的蘋果服務，如iCloud權限、推送、蘋果內購等。

2. iOS簽名原理

2.1 真機調試

相信大多數開發者都實際操做過【申請證書和真機調試】（網上教程也多），那麼問題來了，在【開發者用XCode打包app，並將其安裝到手機】的過程當中，蘋果具體作了什麼？這就要說到蘋果的iOS簽名流程了，能夠用這幅圖歸納：

說明：蘋果官方有一對密鑰，即私鑰和公鑰，私鑰在蘋果後臺，公鑰在iOS系統中（如iPhone手機在出廠後，其中就保存有蘋果官方的公鑰）；在Mac系統打包app時也會生成一對密鑰（私鑰、公鑰），並保存在鑰匙串中。爲了區分這兩對密鑰，將蘋果官方的那對密鑰記爲A，即私鑰A、公鑰A；將Mac系統生成的那對密鑰記爲M，也就是私鑰M、公鑰M。

下面咱們分析一下 iOS的簽名原理（包括簽名與驗證）：

1. XCode在向蘋果服務器申請證書前，會先向鑰匙串申請一個CSR文件，同時生成一對非對稱加密密鑰，也就是私鑰M和公鑰M，並將公鑰M放在CSR中。

2. XCode把CSR文件發送給蘋果服務器，用於申請證書。

3. 蘋果服務器用私鑰A對收到的公鑰M進行簽名，生成Certificate文件（即證書，後綴名爲.cer，裏面有公鑰M）。接着對Certificate、Devices、App ID以及Entitlements一塊兒組成的數據用私鑰A進行簽名，生成Provisioning Profile（即描述文件），並將它發給XCode。

4. iOS項目在編譯完成以後會生成.app文件，你能夠在XCode的Project中找到它。有了.app文件，XCode先使用私鑰M對.app進行簽名，而後，把.app和描述文件一塊兒壓縮成安裝包.ipa文件。

以上爲簽名過程。

補充說明：XCode用私鑰M對.app的簽名分爲兩部分。

1. 是對資源文件的簽名，生成的簽名文件名爲CodeResources，存放在.app目錄下的_CodeSignature文件夾中。
2. 是對app的簽名，其簽名信息存放在Mach-O的Code Signature中。（ps：關於Mach-O，做者之後會專門寫一篇博文講解）

5. XCode準備把安裝包安裝在蘋果設備（如iPhone）上。

6. iPhone對安裝包進行驗證，即用公鑰A驗證描述文件中的簽名。驗證經過則說明描述文件裏的數據是蘋果受權的。

7. 當第【6】步驗證經過後，再用公鑰A驗證證書中的簽名。驗證經過則說明公鑰M是安全可信任的。

8. 第【7】步驗證經過後，就能夠取出描述文件裏的數據作各類驗證，包括用公鑰M驗證App簽名，驗證iPhone是否在設備列表中，App ID是否對得上，使用的權限是否跟Entitlements對應等。當這些所有驗證經過，iPhone就能夠安裝app了。

以上就是iOS簽名的流程分析了，也就是iOS簽名原理。顯然，蘋果用了兩對非對稱加密密鑰，進行的是雙重驗證，基本保證了XCode真機調試的安全性，確保app的安裝行爲是受到蘋果管控的。

理解iOS簽名原理後，再去對照實際申請證書的操做流程，相信你會有新的體會。

引伸：

• Ad Hoc分發流程與上述真機調試流程基本一致。
• In House企業分發流程也是大同小異，只是企業簽名不限制安裝的設備數，只要用戶在iOS系統中信任企業證書，便可安裝該企業證書籤名的app了。

2.2 App Store簽名驗證

最後說一下App Store的簽名驗證，它與前面提到的簽名驗證有所不一樣。當開發者將ipa包上傳到App Store後，蘋果後臺只須要用私鑰A對其簽名便可。當蘋果設備（如iPhone）安裝從App Store下載的安裝包時，會自動用設備中的公鑰A對app的簽名進行驗證，經過後便可正常安裝。

感興趣的同窗能夠去App Store下載ipa包，看看裏面是否有描述文件。

思考：爲何發佈App Store的安裝包時須要用到描述文件？若是證書和描述文件過時或被廢除，會影響App Store上的安裝包嗎？

歡迎你們在下方留言討論~