一、非對稱加密

• 通常說的簽名就是數字簽名，它是基于非對稱加密算法實現的。
• 對稱加密是通過同一份密鑰加密和解密數據，而非對稱加密則有兩份密鑰，分別是公鑰和私鑰，用公鑰加密的數據，要用私鑰才能解密，用私鑰加密的數據，要用公鑰才能解密。
• 非對稱加密算法 RSA 的數學原理：
  ① 選兩個質數 p 和 q，相乘得出一個大整數n，例如p = 61，q = 53，n = pq = 3233；
  ② 選 1-n 間的隨便一個質數e，例如 e = 17；
  ③ 經過一系列數學公式，算出一個數字 d（通過RSA 算法得出），滿足：
  a.通過 n 和 e 這兩個數據一組數據進行數學運算后，可以通過 n 和 d 去反解運算，反過來也可以；
  b.如果只知道 n 和 e，要推導出 d，需要知道 p 和 q，也就是要需要把 n 因數分解；
• 上述的 (n,e) 這兩個數據在一起就是公鑰，(n,d) 這兩個數據就是私鑰，滿足用私鑰加密，公鑰解密，或反過來公鑰加密，私鑰解密，也滿足在只暴露公鑰 (只知道 n 和 e)的情況下，要推導出私鑰 (n,d)，需要把大整數 n 因數分解。
• 目前因數分解只能靠暴力窮舉，而 n 數字越大，越難以用窮舉計算出因數 p 和 q，也就越安全，當 n 大到二進制 1024 位或 2048 位時，以目前技術要破解幾乎不可能，所以非常安全。
• RSA加密的常用方式：公鑰加密，私鑰解密；私鑰簽名，公鑰驗簽。

二、代碼簽名

• 在iOS出來之前，以前的主流操作系統(Mac/Windows)軟件隨便從哪里下載都能運行，系統安全存在隱患，盜版軟件、病毒入侵、靜默安裝等等。那么蘋果希望解決這樣的問題，要保證每一個安裝到 iOS 上的 APP 都是經過蘋果官方允許的，怎樣保證呢？就是通過代碼簽名。
• 如果要實現驗證，其實最簡單的方式：就是通過蘋果官方生成非對稱加密的一對公私鑰。在iOS的系統中內置一個公鑰，私鑰由蘋果后臺保存，我們傳APP到AppStore時，蘋果后臺用私鑰對APP數據進行簽名，iOS系統下載這個APP后，用公鑰驗證這個簽名，若簽名正確，這個APP肯定是由蘋果后臺認證的，并且沒有被修改過，也就達到了蘋果的需求：保證安裝的每一個APP都是經過蘋果官方允許的。

• 如果iOS設備安裝APP只從App Store這一個入口這件事就簡單解決了，沒有任何復雜的東西，一個數字簽名搞定。但是實際上iOS安裝APP還有其他渠道，比如對于開發者iOSER而言，是需要在開發APP時直接真機調試的。而且蘋果還開放了企業內部分發的渠道，企業證書簽名的APP也是需要順利安裝的。
• 蘋果需要開放這些方式安裝APP，這些需求就無法通過簡單的代碼簽名來辦到了。

三、雙向簽名

① 蘋果需求

• 安裝包不需要上傳到App Store，可以直接安裝到手機上；
• 蘋果為了保證系統的安全性，又必須對安裝的APP有絕對的控制權：
  ① 經過蘋果允許才可以安裝；
  ② 不能被濫用導致非開發APP也能被安裝；

② 雙向簽名的原理

• 這里有兩個角色：一個是iOS系統，還有一個就是Mac系統，因為iOS的APP開發環境在Mac系統下，所以這個依賴關系成為了蘋果雙層簽名的基礎。

• 在Mac系統里面使用軟件Xcode生成一對非對稱的加密算法的公鑰和私鑰；公鑰M包含在CSR文件中，私鑰M也就是P12文件保存MAC電腦的keychain中；
• 蘋果服務器也會生成一對固定的公鑰和私鑰，跟之前App Store原理一樣，私鑰在蘋果的后臺，公鑰在我們的iOS設備上這里稱為公鑰A , 私鑰A（A=Apple）；
• 將Mac的公鑰M包裝成CSR文件傳到蘋果后臺之后（通過CSR文件請求證書），蘋果會用私鑰A對CSR文件進行簽名，也就是私鑰A對公鑰M的hash值簽名生成證書，經過蘋果私鑰A加密后，證書再綁定appID及測試開發設備列表，就生成了provisioning profile描述文件，返回給Mac設備；
• 在開發時，編譯完一個 APP 后，將會使用到本地的蘋果企業開發者證書私鑰 M（也即為P12文件）來給APP進行簽名，并將上面得到的證書一塊打包到APP里面，安裝到手機，進行真機調試或者提交審核；
• 在APP進行安裝的時候，iOS系統需要取得內置公鑰來去檢測私鑰的數字簽名的證書是不是正確（iPhone的公鑰A可以解析APP里面的證書）；
• 驗證完成以后就表明APP的安裝時被允許的（也即為鑰M是蘋果認證過的），認證結束就可以保證開發者以及程序的安全；
• iOS上的公鑰A把provisioning profile文件解密了，就驗證了這個APP是經過蘋果官方認證的，同時也得到了測試設備和CSR請求中的公鑰A。再用公鑰 M 去驗證 APP 的簽名，這里就間接驗證了這個 APP 安裝行為是否經過蘋果官方允許（這里只驗證安裝行為，不驗證APP 是否被改動，因為開發階段 APP 內容總是不斷變化的，蘋果不需要管）。

四、描述文件

① 什么是描述文件？

• 有了上面的過程，已經可以保證開發者的認證和程序的安全性了。 但是，你要知道iOS的程序，主要渠道是要通過APP Store才能分發到用戶設備的，如果只有上述的過程，那豈不是只要申請了一個證書，就可以安裝到所有iOS設備了？怎么才能解決“不能被濫用導致非開發APP也能被安裝”的問題呢？
• 蘋果為了解決應用濫用的問題，所以又加了兩個限制：
• • 第一限制在蘋果后臺注冊過的設備才可以安裝；
• • 第二限制簽名只能針對某一個具體的APP。

• 在申請證書之后想要成功的真機調試，還有一個重要步驟，就是分別配置開發模式、發布模式的描述文件吧"XXX.mobileprovision"。必須要在描述文件內部指定設備號，才能調試對應的APP；
• 蘋果是怎樣操作的呢？可以想到蘋果把允許安裝的設備 ID 列表 和 App 對應的 AppID 等數據，都在上面的“雙向簽名”的第三步“私鑰A對CSR文件進行簽名”這里，跟公鑰 M 一起組成證書，再用蘋果私鑰 A 對這個證書簽名。在最后“內置公鑰來去檢測私鑰的數字簽名的證書”這一步驗證時，就可以拿到設備 ID 列表，判斷當前設備是否符合要求。根據數字簽名的原理，只要數字簽名通過驗證，這里的設備 IDs / AppID / 公鑰 M 就都是經過蘋果認證的，無法被修改，蘋果就可以限制可安裝的設備和 App，避免濫用。
• 蘋果還想控制App里面的iCloud/PUSH/后臺運行/調試器附加這些權限，所以蘋果把這些權限開關統一稱為Entitlements(授權文件)，并將這個文件放在了一個叫做Provisioning Profile(描述文件)文件中；
• 描述文件是在AppleDevelop網站創建的(在Xcode中填上AppleID它會代辦創建)，Xcode運行時會打包進入APP內。所以使用CSR申請證書時，我們還要申請一個東西， 這就是描述文件。
• 在開發時，編譯完一個 APP 后，用本地的私鑰M對這個APP進行簽名，同時把從蘋果服務器得到的 Provisioning Profile 文件打包進APP里，文件名為embedded.mobileprovision，把 APP 安裝到手機上，最后系統進行驗證。

② 描述文件的信息

• 描述文件（Provisioning profile）一般包括三樣東西：證書、App ID、設備。當在真機運行或者打包一個項目的時候，證書用來證明程序的安全性和合法性。
• 描述文件的路徑：

• 打開終端，輸入命令（security cms -Di ）+ 描述文件名，就可以查看對應描述文件的全部詳情信息（即為 plist 文件）；
• 可將信息全部復制到 Xcode 工程的 plist 文件中直觀查看：

總結

以上是生活随笔為你收集整理的iOS逆向之深入解析App签名的双向验证机制和原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。