iOS應用簽名原理

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

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

數據傳輸

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

假如發送方直接將原始數據明文傳輸給接收方時，數據非常不安全，極易被篡改；為了提升安全性並同時簡化明文，可以對數據進行 哈希算法 處理，得到原始數據的 摘要 ，然後將摘要發送給接收方。但假如哈希算法被泄漏，依然存在數據被篡改的風險；引入 非對稱加密算法 ，對一份數據，用 哈希算法 計算出摘要後，再用 RSA 的 私鑰 加密摘要，得到原始數據的數字簽名， 發送方將數字簽名與原始數據一起發送給接收方 。

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

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

數字簽名驗證

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

接收方拿到數據後，通過同樣的 哈希加密處理原始數據 ，得到哈希值（摘要）；再利用 非對稱將數字簽名中的校驗哈希值（摘要）解密 出來；最後對比兩個哈希值是否一致，判斷出數據是否被篡改。

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

再來看看如何利用數字簽名保證每個安裝到 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 IDEntitlements（權限）注冊設備列表其它關乎 App 能否正常啟動的所有信息

所以我們猜測簽名的大概流程是這樣的：

在開發設備 Mac 上本地生成一對公私鑰。Apple 有一對公私鑰，Apple 私鑰在 Apple 後台，Apple 公鑰在每台 iOS 設備上。把 Mac 公鑰上傳到 Apple 後台，用 Apple 私鑰簽名 Mac 公鑰，可以得到一份 Mac 公鑰和簽名的組合數據，我們把這份數據稱為 證書 。在 Apple 後台申請 App ID，配置好的 UDID（注冊設備） 列表以及 App 申請的權限（Entitlements），再加上步驟3中的證書，組合起來的數據用 Apple 私鑰進行簽名，把數據和簽名一起組成 PP 文件，下載到本地的開發設備 Mac 上。當我們編譯工程時，Mac 私鑰會對 App 進行簽名，同時把步驟4得到的 PP 文件打包進去，文件名為 embedded.mobileprovision ，準備將 App 安裝到手機上。安裝時，iOS 係統取得證書，通過係統內置的 Apple 公鑰，去驗證證書裏的簽名是否正確。繼續用 Apple 公鑰驗證描述文件是否正確。用 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 包為例的簽名和驗證的流程，隻是企業簽名不限製安裝的設備數，因此描述文件中不會有設備列表，而是一條 ProvisionsAllDevices 記錄。

而從 App Store 上下載的安裝包，裏麵是沒有描述文件的，但上架之前還是要配置證書、PP 文件，因為 App ID 和權限的檢驗還是需要做的。但 App 上傳到 AppStore 以後就跟 PP 文件沒有關係了，所以我們可以理解為 App Store 上包的簽名驗證采用就是前麵說的最簡單的簽名方式，Apple 後台直接用私鑰簽名 App 就可以了。