為了確保 iOS 平臺(tái)對(duì) App 擁有絕對(duì)的控制權(quán)，不至出現(xiàn)盜版軟件盛行的局面，Apple 采取了簽名機(jī)制。
預(yù)備知識(shí)
1.非對(duì)稱加密算法
討論 iOS App 簽名機(jī)制之前，必須先了解一下非對(duì)稱加密機(jī)制。顧名思義，非對(duì)稱加密是相對(duì)對(duì)稱加密來說的，前者需要兩個(gè)密鑰，即私鑰和與之匹配的公鑰，用其中之一加密，必須用另一個(gè)解密；而后者只有一個(gè)密鑰，如下圖：
2.數(shù)字簽名
說完了非對(duì)稱加密，我們?cè)賮砜纯春灻鞘裁礀|東吧。簽名就表示認(rèn)可，它的作用是對(duì)一份數(shù)據(jù)做一個(gè)標(biāo)記，然后將這份數(shù)據(jù)發(fā)給接收方，接收方通過上邊的標(biāo)記就可以確認(rèn)這份數(shù)據(jù)是否曾被篡改過的?；镜暮灻膀?yàn)證簽名過程如下：
首先，生成一對(duì)非對(duì)稱加密使用的密鑰 (公鑰+私鑰)，私鑰留在服務(wù)端，公鑰發(fā)布出去；
然后，使用 HASH 算法 (最常用如 MD5) 得到原始數(shù)據(jù)的一個(gè)摘要，然后用私鑰加密這個(gè)摘要，加密后的數(shù)據(jù)即稱為原始數(shù)據(jù)的簽名，把它和原始數(shù)據(jù)一起發(fā)送給用戶；
最后，用戶接收到原始數(shù)據(jù)和簽名后，使用服務(wù)端發(fā)布出來的公鑰解密簽名，得到一個(gè)摘要 A。同時(shí)，用戶使用同樣的 HASH 算法生成原始數(shù)據(jù)的摘要 B，然后比較摘要 A 和 摘要 B，如果相等，說明數(shù)據(jù)未被篡改，否則，數(shù)據(jù)就被改動(dòng)過。
補(bǔ)充：HASH 算法的特點(diǎn)是：①不可逆，即不能通過結(jié)果得到原始數(shù)據(jù)；②運(yùn)算結(jié)果的長度固定，且比較短。
iOS App 的簽名機(jī)制
iOS App 目前有以下幾種安裝方式：
1.AppStore 下載的 App可以在手機(jī)上安裝。
2.開發(fā)過程中，可以直接 App 安裝進(jìn)手機(jī)進(jìn)行調(diào)試。
3.In-House 企業(yè)內(nèi)部分發(fā)，可以直接安裝企業(yè)證書簽名后的 APP。
4.AD-Hoc 相當(dāng)于企業(yè)分發(fā)的限制版，它限制了安裝設(shè)備的數(shù)量。
下面以前 2 種情況為例，討論一下 iOS App 的簽名機(jī)制。
1.AppStore
這種方式的實(shí)現(xiàn)比較簡單，由蘋果官方生成一對(duì)密鑰(public-key/private-key)，公鑰 （public-key）內(nèi)置到 iOS 設(shè)備里，私鑰（private-key）由蘋果服務(wù)器保存。
當(dāng)我們往 AppStore 上傳 App 時(shí)，蘋果服務(wù)器會(huì)用私鑰（private-key）對(duì) App 數(shù)據(jù)進(jìn)行簽名，iOS 系統(tǒng)下載這個(gè) App 后，用設(shè)備自帶的公鑰（public-key）驗(yàn)證這個(gè)簽名，若簽名正確，說明這個(gè) App 肯定是由蘋果認(rèn)證的，并且沒有被修改過，這樣就保證了安裝的每一個(gè) App 都是經(jīng)過蘋果官方允許的。
補(bǔ)充：把 App 上傳 AppStore 后，蘋果還會(huì)對(duì) App 進(jìn)行加密。
2.開發(fā)階段
當(dāng)開發(fā) App 的時(shí)候，需要頻繁的安裝 App 到手機(jī)上，如果每次都先將 App 包傳給蘋果服務(wù)器，得到授權(quán)后才可以安裝，那對(duì)開發(fā)者來說簡直是災(zāi)難，而事實(shí)上，蘋果也確實(shí)沒有這么做，而是可以直接安裝在手機(jī)上。
不過，蘋果依然要求對(duì) App 的安裝有控制權(quán)，即：
① 必須經(jīng)過蘋果允許才可以安裝；
② 權(quán)利不能被濫用，非開發(fā)狀態(tài)的 App 不允許安裝。
為了實(shí)現(xiàn)這些苛刻的要求，iOS 簽名的復(fù)雜度也就增加了，蘋果給出的解決方案是使用雙重簽名，大概流程見下圖：
在開發(fā)機(jī)器（如 iMac、MacBook Pro 及 Mac mini）上創(chuàng)建一個(gè)密鑰對(duì) (公鑰 local / 私鑰 local)。即 通過 keychain 里邊的 “從證書頒發(fā)機(jī)構(gòu)請(qǐng)求證書” 創(chuàng)建，私鑰存在本機(jī)，公鑰就是得到的 CertificateSigningRequest。
蘋果自己有固定的一個(gè)密鑰對(duì) (公鑰 Apple / 私鑰 Apple)，跟上面 AppStore 例子一樣，私鑰在蘋果服務(wù)端，公鑰在每個(gè) iOS 設(shè)備上。
把公鑰 local 傳到蘋果服務(wù)端，用蘋果服務(wù)端的私鑰 Apple 去簽名公鑰 local，得到一份證書，其中包含了公鑰 local 及其簽名。
在蘋果后臺(tái)申請(qǐng) AppID，配置好設(shè)備 ID 列表和 App 可使用的權(quán)限，然后將這些數(shù)據(jù)連同上一步獲得的證書一起用私鑰 A 簽名，把數(shù)據(jù)和簽名合成一個(gè) Provisioning Profile 文件，即通常所說的 xxx.mobileprovision 文件，下載到本地的開發(fā)機(jī)器。
在開發(fā)時(shí)，編譯完一個(gè) App 后，用私鑰 local 對(duì)這個(gè) App 進(jìn)行簽名，同時(shí)把上一步得到的? xxx.mobileprovision 打包進(jìn) App 里，文件更名為 embedded.mobileprovision，然后把 App 安裝到手機(jī)上。
在安裝時(shí)，iOS 系統(tǒng)取得證書，通過 iOS 設(shè)備內(nèi)置的公鑰 Apple，去驗(yàn)證 embedded.mobileprovision 的數(shù)字簽名是否正確。
如果上一步驗(yàn)證簽名成功，就可以取出 embedded.mobileprovision 里面的數(shù)據(jù)，做各種驗(yàn)證，具體包括：用公鑰 local 驗(yàn)證 App 簽名，驗(yàn)證當(dāng)前 iOS 設(shè)備的 ID 是否在 設(shè)備 IDs 上，AppID 與當(dāng)前 App 的 ID 是否對(duì)應(yīng)得上，權(quán)限是否跟 App 里 Entitlements 的描述一致。
In-House 企業(yè)內(nèi)部分發(fā)和 AD-Hoc 原理相似，只是企業(yè)內(nèi)部分發(fā)不限制安裝的設(shè)備數(shù)量，另外需要用戶在 iOS 系統(tǒng)設(shè)置里邊手動(dòng)點(diǎn)擊信任這個(gè)企業(yè)才能通過驗(yàn)證。
以上就是我所了解的 iOS App 的簽名機(jī)制，其實(shí)只是個(gè)大概，還有許多細(xì)節(jié)可以深挖，以后再加吧！
