iOS 應用簽名原理

歡迎訪問個人博客原文

很多果粉對 Apple 鍾情，與它的純淨、安全有很大關係，咱們發如今蘋果的設備上下載應用時，不會出現觸發下載一系列垃圾軟件的狀況，並且用戶能夠明確 App 的來源——經過官方商店 AppStore 購買、企業證書安裝仍是 TestFlight 下載。爲了防止盜版軟禁、病毒入侵、靜默安裝以及屏蔽其它不可控因素，並確保每個安裝到 iOS 設備上的應用都是被官方容許的，蘋果設定了一套應用簽名機制。

數字簽名

數字簽名，又稱公鑰數字簽名，是隻有信息的發送者才能產生的別人沒法僞造的一段數字串，發送者對要發送的數據打上簽名標記，表示這份通過認證，未被篡改的。

數據傳輸

下面模擬一下數據傳輸的過程：

1. 假如發送方直接將原始數據明文傳輸給接收方時，數據很是不安全，極易被篡改；

2. 爲了提高安全性並同時簡化明文，能夠對數據進行哈希算法處理，獲得原始數據的摘要，而後將摘要發送給接收方。但假如哈希算法被泄漏，依然存在數據被篡改的風險；

3. 引入非對稱加密算法，對一份數據，用哈希算法計算出摘要後，再用 RSA 的私鑰加密摘要，獲得原始數據的數字簽名，發送方將數字簽名與原始數據一塊兒發送給接收方。

咱們將原始數據進行哈希加密、非對稱加密後的數據稱爲數字簽名。

接收方拿到數據後，須要進行簽名驗證，來確保數據傳輸過程當中，未被篡改。

數字簽名驗證

簽名驗證的具體步驟以下：

1. 接收方拿到數據後，經過一樣的哈希加密處理原始數據，獲得哈希值（摘要）；

2. 再利用非對稱將數字簽名中的校驗哈希值（摘要）解密出來；

3. 最後對比兩個哈希值是否一致，判斷出數據是否被篡改。

用一張圖還原數字簽名的完整過程：

再來看看如何利用數字簽名保證每一個安裝到 iOS 上的 App 都被蘋果認證容許。

代碼簽名

代碼簽名就是對可執行文件或腳本進行數字簽名，用來確認軟件在簽名後未被修改或損壞的措施。它的原理和數字簽名相似，只不過把簽名的不是數據，而是代碼。

簡單的代碼簽名

假如 App 是隻能從 App Store 上下載，那麼它的驗證方式就比較簡單了。

由蘋果官方生成一對公私鑰，在 iOS 系統中內置一個公鑰，私鑰由蘋果後臺保存。

咱們把 App 上傳到 App Store 時，蘋果後臺用私鑰對 App 數據進行簽名，iOS 系統下載這個 App 後，用公鑰驗證這個簽名，若是簽名正確則這個 App 確定是由蘋果後臺認證的，而且沒有被修改或損壞。

但 iOS 設備安裝 App 並不僅有 App Store 這一個渠道，好比開發者的真機調試、TestFlight 內測、In-House 企業證書分發等，此時簡單的代碼簽名就沒法知足對 App 的徹底驗證了。

iOS 代碼簽名的複雜度須要相應增長，因而雙層代碼簽名（雙重簽名）產生了。

雙層代碼簽名

「雙層」意在用兩對公私鑰作加密驗證，它們分別是 Mac 本地的一對和 Apple 服務提供的一對。

雙層代碼簽名的存在是爲了知足：

• App 須要通過蘋果容許才能安裝；
• 在 Apple 後臺中註冊過的設備才能安裝，好比在 TestFlight 內測、真機調試模式下；
• 限制簽名只能對應惟一的 App。

爲了猜想完整的簽名流程，咱們能夠解壓一個 ipa 文件，在 Payload 目錄中有一個 embedded.mobileprovision，咱們稱之爲描述文件，它對應的是 Apple 後臺生成 Provisioning Profile（簡稱 PP）文件。文件中包括：

• 證書（公鑰、簽名）
• App ID
• Entitlements（權限）
• 註冊設備列表
• 其它關乎 App 可否正常啓動的全部信息

因此咱們猜想簽名的大概流程是這樣的：

1. 在開發設備 Mac 上本地生成一對公私鑰。

2. Apple 有一對公私鑰，Apple 私鑰在 Apple 後臺，Apple 公鑰在每臺 iOS 設備上。

3. 把 Mac 公鑰上傳到 Apple 後臺，用 Apple 私鑰簽名 Mac 公鑰，能夠獲得一份 Mac 公鑰和簽名的組合數據，咱們把這份數據稱爲證書。

4. 在 Apple 後臺申請 App ID，配置好的 UDID（註冊設備） 列表以及 App 申請的權限（Entitlements），再加上步驟3中的證書，組合起來的數據用 Apple 私鑰進行簽名，把數據和簽名一塊兒組成 PP 文件，下載到本地的開發設備 Mac 上。

5. 當咱們編譯工程時，Mac 私鑰會對 App 進行簽名，同時把步驟4獲得的 PP 文件打包進去，文件名爲 embedded.mobileprovision，準備將 App 安裝到手機上。

6. 安裝時，iOS 系統取得證書，經過系統內置的 Apple 公鑰，去驗證證書裏的簽名是否正確。

7. 繼續用 Apple 公鑰驗證描述文件是否正確。

8. 用 Mac 公鑰驗證 App 簽名是否被篡改。

上面的步驟對應到實際操做和概念是這樣的：

第 1 步：Mac 上依次打開「鑰匙串訪問 → 證書助理 → 從證書頒發機構請求證書...」，作了這一步，就會在本地生成了一對公私鑰，導出的 CSR 文件（CertificateSigningRequest.certSigningRequest）就是 Mac 公鑰，Mac 私鑰也是存儲在本地，具體是什麼文件看第 3 步。

第 2 步：每臺 iOS 設備中都已經有了 Apple 公鑰，至於 Apple 私鑰是什麼，看第 3 步。

第 3 步：在 Apple 後臺的 iOS Certificates 模塊，經過上傳本地導出的 CSR 文件，生成 .cer 證書文件，也就是 Apple 私鑰。將 .cer 證書下載到本地，安裝證書，在鑰匙串中找到證書，就能夠導出 Mac 私鑰，也就是一個 .p12 文件。它和第 1 步中導出的 Mac 公鑰是對應的，鑰匙串會把這兩個證書關聯起來。用.cer 證書去簽名 CSR 文件，拿到含有簽名的證書。

第 4 步：在 Apple 後臺配置 App ID、Entitlements、Devices 等，而後下載 PP 文件。

第 5 步：編譯 App 時，XCode 會經過第 3 步下載回來的證書（存着 Mac 公鑰），在本地找到對應的 Mac 私鑰，而後用 Mac 私鑰去簽名 App，同時打包，安裝包中包含 PP 文件，在 ipa 中的文件名是 embedded.mobileprovision。這裏 App 的簽名數據被分爲兩部分，Mach-O 可執行文件會把簽名直接寫入描述文件裏，而資源文件則會保存在 _CodeSignature 目錄下，這時準備安裝 App。

第 6 步：使用 Apple 公鑰驗證描述文件簽名，對應第 4 步，簽名經過，說明證書可用，進入下一步。

第 7 步：使用 Apple 公鑰驗證證書籤名，對應第 3 步，簽名經過，說明 Mac 公鑰合法，進入下一步。

第 8 步：使用 Mac 公鑰驗證 App 簽名，對應第 4 步，上述驗證均經過後，還須要將描述文件中的內容與 App 自己的信息作驗證對比，好比驗證設備 ID 是否在 UDID 列表上，App ID 是否相同，權限開關是否與 Entitlements 一致，都驗證經過，就能夠開始安裝 App。

前面說了，雙層代碼簽名是針對開發測試包、In-House 企業簽名、Ad-Hoc 包爲例的簽名和驗證的流程，只是企業簽名不限制安裝的設備數，所以描述文件中不會有設備列表，而是一條 <key>ProvisionsAllDevices</key><true/> 記錄。

而從 App Store 上下載的安裝包，裏面是沒有描述文件的，但上架以前仍是要配置證書、PP 文件，由於 App ID 和權限的檢驗仍是須要作的。但 App 上傳到 AppStore 之後就跟 PP 文件沒有關係了，因此咱們能夠理解爲 App Store 上包的簽名驗證採用就是前面說的最簡單的簽名方式，Apple 後臺直接用私鑰簽名 App 就能夠了。