iOS APP簽名機制詳解

蘋果的需求

1. 爲了保證系統的安全性，全部iPhone上安裝的應用必須是通過蘋果受權的
2. 安裝包不須要上傳到App Store也能被安裝 （開發調試 企業灰度）
3. 防止證書權限濫用：設備限制、指定APP、iCloud/PUSH/後臺運行等附加權限控制

蘋果的解決方案：雙層代碼簽名+描述文件:

這裏畫一張圖附上：

 在iOS出來以前，主流的操做系統（MacOS/Windows）軟件隨便從哪裏下載都能運行，系統安全存在隱患，盜版軟件、病毒入侵、靜默安裝等等，蘋果但願解決相似的問題，保證在iPhone iOS上的APP都是通過蘋果官方容許的，怎樣保證呢？就是經過 代碼簽名。

 若是要實現驗證，最簡單的方式就是蘋果官方生成一對RSA公私鑰，在iOS系統中內置一個公鑰，私鑰由蘋果後臺保存，咱們上傳APP到App Store時蘋果後臺用私鑰對APP數據進行加密，iPhone下載APP後用公鑰驗證這個簽名就能夠確認APP是否通過容許或被三方篡改過。可是，咱們安裝APP並不單單隻有App Store這一個方式，好比真機調試、企業包等，因此只靠這個簡單的數字簽名方式是不夠的。

 因而蘋果設計了雙層簽名的機制，咱們都知道iOS的應用開發必須在Mac系統下進行，正是因爲這個依賴關係，雙層簽名纔有了基礎：

1. 在Mac系統中生成一對非對稱加密算法的公私鑰M（Xcode會幫你作好）
2. 蘋果本身有固定的一對公私鑰，正如上述最簡單的代碼簽名中提到的：私鑰A在蘋果後臺，公鑰A在每一個iOS系統的手機中
3. 把公鑰M以及一些開發者信息（也就是CSR文件）發送給蘋果後臺，用蘋果後臺的私鑰A對公鑰M簽名，獲得一份包含公鑰M以及其簽名結果的數據就是證書（.p12）。
4. 在開發時，當咱們打包時會用本地的私鑰M（也就是可導出給小夥伴的開發者證書）對這個APP進行簽名，同時把第三步獲得的證書一塊兒打包進APP裏，而後安裝到手機上（真機聯調）或者提交App Store審覈
5. 安裝時，iOS系統取得內置公鑰A去驗證公鑰M的數字簽名證書是否正確
6. 驗證公鑰M是蘋果認證過的後，再用公鑰M去驗證APP的簽名，這樣就間接驗證了這個APP的安裝是通過蘋果容許的了（注意這裏只驗證安裝行爲，不驗證APP是否被改動，由於開發階段APP內容老是不斷變化的）

 有了上面的過程已經能夠保證開發者的認證和程序的安全了，可是若是隻有上述的過程，那豈不是隻要申請了一個證書就能夠安裝到全部的iOS設備了？因此，蘋果又增長了受權文件（Provisioning profile）的驗證，Provisioning profile通常包括三樣東西：證書、APP ID、設備。

 描述文件是在AppleDevelop網站建立的(在Xcode中填上AppleID它會代辦建立)，Xcode運行時會打包進入APP內。在開發時，編譯完一個 APP 後，用本地的私鑰M對這個APP進行簽名，同時把從蘋果服務器獲得的 Provisioning Profile 文件打包進APP裏，文件名爲embedded.mobileprovision，當把APP安裝到手機上時，iOS系統會進行驗證。

 以上就是iOS應用簽名的原理，下一篇我會基於這個原理給你們手擼一個自動重簽名的腳本。