不少果粉對 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 能否正常啟動的所有資訊

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

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

第 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 就可以了。