代碼簽名是對可執行文件或者腳本進行數字簽名,用來確認軟件在簽名後未被修改或損壞的措施。安全
簡單的代碼簽名服務器
在iOS出來以前,之前的主流操做系統(Mac/Windows)軟件隨便從哪裏下載都能運行,系統存在安全隱患,盜版軟件、病毒入侵、靜默安裝等等。蘋果但願解決這樣的問題,就必須保證每個安裝到iOS上的App都是通過蘋果官方容許的,那麼怎樣保證呢?就是經過代碼簽名。網站
若是要實現驗證,最簡單的方式就是經過蘋果官方生成非對稱加密的一對公私鑰。在iOS系統中內置一個公鑰,私鑰由蘋果後臺保存,咱們傳App到AppStore時,蘋果後臺用私鑰對App數據進行簽名,iOS設備下載這個App後,用公鑰驗證這個簽名,若簽名正確,那麼就證實這個App是由蘋果後臺認證過的,而且沒有被修改過,這就達到了蘋果的目的,確保了每個App都是官方容許的。加密
若是咱們iOS設備安裝App只是從AppStore這一個入口,那麼事情就很簡單了,一個數字簽名搞定。 可是實際上iOS安裝App還有其餘渠道,好比對於開發者而言,須要真機調試,並且蘋果還開放了企業內部分發渠道,企業證書籤名的App也是須要順利安裝的。 蘋果須要開放這些方式安裝App,那麼簡單的代碼簽名就沒法實現了。操作系統
iOS的雙層代碼簽名流程這裏簡單梳理一下,這也不是最終的iOS簽名原理,iOS的最終簽名在這個基礎上還要稍微加點東西。 首先這裏有兩個角色:一個是iOS系統,還有一個就是咱們的Mac系統,由於iOS的APP開發環境在Mac系統下。因此這個依賴關係成爲了蘋果雙層簽名的基礎。調試
簽名流程以下:code
一、Mac上建立一個密鑰對 (公鑰Mac 和 私鑰Mac),即經過「鑰匙串」裏邊的 「從證書頒發機構請求證書」 建立,私鑰存在本機,公鑰包含在CertificateSigningRequest文件中。cdn
二、將CSR文件上傳至蘋果服務器,蘋果服務器用 私鑰Apple 對CSR的哈希值進行加密,生成一個證書(證書裏包含了公鑰Mac和其通過私鑰Apple加密過的哈希值)blog
三、在開發編譯階段,每次編譯結束,Mac會用 私鑰Mac(p12文件) 對App進行簽名,並把上一步獲得的證書打包進App,此時App裏包含了上一步生成的證書(證書裏包含了公鑰Mac和其通過私鑰Apple加密過的哈希值)開發
四、iPhone設備安裝App時,先經過設備內置的公鑰Apple對上一步的哈希值進行解密來得到證書,進而得到公鑰Mac,若是解密成功,表示該證書是蘋果服務器頒發,接下來就能夠拿到 公鑰Mac 對App包的簽名進行解密,由於該App是經過 私鑰Mac進行簽名的,此時就能夠驗證成功進行安裝。
經過上面的簽名流程進行分析,若是蘋果的簽名流程只有這幾個過程,豈不是隻要申請了一個證書,就能夠安裝到全部iOS設備了?
蘋果爲了解決應用濫用的問題,又加了兩個限制:
描述文件是AppleDevelop網站建立的(在Xcode中填上AppleID它會代辦建立),Xcode運行時會打包進入APP內.因此咱們使用CSR申請證書時,咱們還要申請一個東西!! 就是描述文件!
在開發時,編譯完一個 APP 後,用本地的私鑰Mac對這個APP進行簽名,同時把從蘋果服務器獲得的 Provisioning Profile 文件打包進APP裏,文件名爲embedded.mobileprovision,把 APP 安裝到手機上.在手機安裝App時,先去解密獲得Provisioning Profile 文件,而後再作各類驗證,作各類驗證,具體包括:用公鑰Mac 驗證 App 簽名,驗證當前 iOS 設備的 ID 是否在 設備 IDs 上,AppID 與當前 App 的 ID 是否對應得上,權限是否跟 App 裏 Entitlements 的描述一致等等。
由於描述文件也須要作祕鑰的驗證,因此咱們沒辦法修改描述文件裏的東西,不然會驗證不經過,只能在蘋果開發者中心去申請描述文件。
根據上面的簽名原理,App的簽名是由本地Xcode來完成的,因此咱們能夠把一些IPA包放到咱們的工程編譯完成後的目錄裏,讓Xcode誤認爲此IPA是咱們工程編譯產生的,進而用咱們本身的bundleid、本身的證書對其進行簽名,從而實現了App的重簽名。
若是是用我的證書籤名,那麼須要刪除IPA裏的PlugIns和Watch,由於我的證書沒法簽名Extention。