iOS 簽名機(jī)制挺復(fù)雜，各種證書，Provisioning Profile峰髓，entitlements，CertificateSigningRequest浪汪，p12呀潭，AppID，概念一堆狸棍，也很容易出錯(cuò)，本文嘗試從原理出發(fā)，一步步推出為什么會(huì)有這么多概念见擦，希望能有助于理解 iOS App 簽名的原理和流程卢未。
目的
先來(lái)看看蘋果的簽名機(jī)制是為了做什么戳葵。在 iOS 出來(lái)之前戏自，在主流操作系統(tǒng)(Mac/Windows/Linux)上開(kāi)發(fā)和運(yùn)行軟件是不需要簽名的，軟件隨便從哪里下載都能運(yùn)行徘铝，導(dǎo)致平臺(tái)對(duì)第三方軟件難以控制，盜版流行。蘋果希望解決這樣的問(wèn)題缸废，在 iOS 平臺(tái)對(duì)第三方 APP 有絕對(duì)的控制權(quán)，一定要保證每一個(gè)安裝到 iOS 上的 APP 都是經(jīng)過(guò)蘋果官方允許的四苇，怎樣保證呢煌集？就是通過(guò)簽名機(jī)制。
非對(duì)稱加密
通常我們說(shuō)的簽名就是數(shù)字簽名乍赫，它是基于非對(duì)稱加密算法實(shí)現(xiàn)的溪猿。對(duì)稱加密是通過(guò)同一份密鑰加密和解密數(shù)據(jù)怎披，而非對(duì)稱加密則有兩份密鑰，分別是公鑰和私鑰口渔，用公鑰加密的數(shù)據(jù)咧党，要用私鑰才能解密，用私鑰加密的數(shù)據(jù)芭概，要用公鑰才能解密桩蓉。
簡(jiǎn)單說(shuō)一下常用的非對(duì)稱加密算法 RSA 的數(shù)學(xué)原理偏友，理解簡(jiǎn)單的數(shù)學(xué)原理窿冯，就可以理解非對(duì)稱加密是怎么做到的，為什么會(huì)是安全的：
選兩個(gè)質(zhì)數(shù) p 和 q漱竖，相乘得出一個(gè)大整數(shù)n良狈，例如 p=61漫玄，q=53询一，n=pq=3233
選 1-n 間的隨便一個(gè)質(zhì)數(shù) e掂之，例如 e = 17
經(jīng)過(guò)一系列數(shù)學(xué)公式震蒋，算出一個(gè)數(shù)字 d直砂，滿足：
a. 通過(guò) n 和 e 這兩個(gè)數(shù)據(jù)一組數(shù)據(jù)進(jìn)行數(shù)學(xué)運(yùn)算后泪掀，可以通過(guò) n 和 d 去反解運(yùn)算量九，反過(guò)來(lái)也可以。
b. 如果只知道 n 和 e对雪，要推導(dǎo)出 d，需要知道 p 和 q禁荒，也就是要需要把 n 因數(shù)分解污它。
上述的 (n,e) 這兩個(gè)數(shù)據(jù)在一起就是公鑰镇辉，(n,d) 這兩個(gè)數(shù)據(jù)就是私鑰评腺，滿足用公鑰加密，私鑰解密给猾，或反過(guò)來(lái)公鑰加密，私鑰解密揭保，也滿足在只暴露公鑰（只知道 n 和 e）的情況下匕得，要推導(dǎo)出私鑰 (n,d)当娱，需要把大整數(shù) n 因數(shù)分解。目前因數(shù)分解只能靠暴力窮舉猴鲫，而n數(shù)字越大拂共，越難以用窮舉計(jì)算出因數(shù) p 和 q咱台，也就越安全，當(dāng) n 大到二進(jìn)制 1024 位或 2048 位時(shí)翼岁，以目前技術(shù)要破解幾乎不可能，所以非常安全凌盯。
若對(duì)數(shù)字 d 是怎樣計(jì)算出來(lái)的感興趣，可以詳讀這兩篇文章：RSA 算法原理（一）（二）
數(shù)字簽名
現(xiàn)在知道了有非對(duì)稱加密這東西继效，那數(shù)字簽名是怎么回事呢症杏？
數(shù)字簽名的作用是我對(duì)某一份數(shù)據(jù)打個(gè)標(biāo)記，表示我認(rèn)可了這份數(shù)據(jù)（簽了個(gè)名）瑞信，然后我發(fā)送給其他人厉颤，其他人可以知道這份數(shù)據(jù)是經(jīng)過(guò)我認(rèn)證的，數(shù)據(jù)沒(méi)有被篡改過(guò)喧伞。
有了上述非對(duì)稱加密算法走芋，就可以實(shí)現(xiàn)這個(gè)需求：
1.首先用一種算法，算出原始數(shù)據(jù)的摘要潘鲫。需滿足 a.若原始數(shù)據(jù)有任何變化翁逞，計(jì)算出來(lái)的摘要值都會(huì)變化。 b.摘要要夠短溉仑。這里最常用的算法是MD5挖函。
- 生成一份非對(duì)稱加密的公鑰和私鑰，私鑰我自己拿著浊竟，公鑰公布出去怨喘。
- 對(duì)一份數(shù)據(jù)津畸，算出摘要后，用私鑰加密這個(gè)摘要必怜，得到一份加密后的數(shù)據(jù)肉拓，稱為原始數(shù)據(jù)的簽名。把它跟原始數(shù)據(jù)一起發(fā)送給用戶梳庆。
- 用戶收到數(shù)據(jù)和簽名后暖途，用公鑰解密得到摘要。同時(shí)用戶用同樣的算法計(jì)算原始數(shù)據(jù)的摘要膏执，對(duì)比這里計(jì)算出來(lái)的摘要和用公鑰解密簽名得到的摘要是否相等驻售，若相等則表示這份數(shù)據(jù)中途沒(méi)有被篡改過(guò)，因?yàn)槿绻鄹倪^(guò)更米，摘要會(huì)變化欺栗。
之所以要有第一步計(jì)算摘要，是因?yàn)榉菍?duì)稱加密的原理限制可加密的內(nèi)容不能太大（不能大于上述 n 的位數(shù)征峦，也就是一般不能大于 1024 位/ 2048 位）迟几，于是若要對(duì)任意大的數(shù)據(jù)簽名，就需要改成對(duì)它的特征值簽名栏笆，效果是一樣的瘤旨。
好了，有了非對(duì)稱加密的基礎(chǔ)竖伯，知道了數(shù)字簽名是什么，怎樣可以保證一份數(shù)據(jù)是經(jīng)過(guò)某個(gè)地方認(rèn)證的因宇，來(lái)看看怎樣通過(guò)數(shù)字簽名的機(jī)制保證每一個(gè)安裝到 iOS 上的 APP 都是經(jīng)過(guò)蘋果認(rèn)證允許的七婴。
最簡(jiǎn)單的簽名
要實(shí)現(xiàn)這個(gè)需求很簡(jiǎn)單，最直接的方式察滑，蘋果官方生成一對(duì)公私鑰打厘，在 iOS 里內(nèi)置一個(gè)公鑰，私鑰由蘋果后臺(tái)保存贺辰，我們傳 App 上 AppStore 時(shí)户盯，蘋果后臺(tái)用私鑰對(duì) APP 數(shù)據(jù)進(jìn)行簽名，iOS 系統(tǒng)下載這個(gè) APP 后饲化，用公鑰驗(yàn)證這個(gè)簽名莽鸭，若簽名正確，這個(gè) APP 肯定是由蘋果后臺(tái)認(rèn)證的吃靠，并且沒(méi)有被修改過(guò)硫眨，也就達(dá)到了蘋果的需求：保證安裝的每一個(gè) APP 都是經(jīng)過(guò)蘋果官方允許的。
如果我們 iOS 設(shè)備安裝 APP 只有從 AppStore 下載這一種方式的話巢块，這件事就結(jié)束了礁阁，沒(méi)有任何復(fù)雜的東西巧号，只有一個(gè)數(shù)字簽名，非常簡(jiǎn)單地解決問(wèn)題姥闭。
但實(shí)際上因?yàn)槌藦?AppStore 下載丹鸿，我們還可以有三種方式安裝一個(gè) App：
開(kāi)發(fā) App 時(shí)可以直接把開(kāi)發(fā)中的應(yīng)用安裝進(jìn)手機(jī)進(jìn)行調(diào)試。
In-House 企業(yè)內(nèi)部分發(fā)棚品，可以直接安裝企業(yè)證書簽名后的 APP靠欢。
AD-Hoc 相當(dāng)于企業(yè)分發(fā)的限制版，限制安裝設(shè)備數(shù)量南片，較少用掺涛。
蘋果要對(duì)用這三種方式安裝的 App 進(jìn)行控制，就有了新的需求疼进，無(wú)法像上面這樣簡(jiǎn)單了薪缆。
新的需求
我們先來(lái)看第一個(gè)，開(kāi)發(fā)時(shí)安裝APP伞广，它有兩個(gè)個(gè)需求：
安裝包不需要傳到蘋果服務(wù)器拣帽，可以直接安裝到手機(jī)上。如果你編譯一個(gè) APP 到手機(jī)前要先傳到蘋果服務(wù)器簽名嚼锄，這顯然是不能接受的减拭。
蘋果必須對(duì)這里的安裝有控制權(quán)，包括
a.經(jīng)過(guò)蘋果允許才可以這樣安裝区丑。
b.不能被濫用導(dǎo)致非開(kāi)發(fā)app也能被安裝拧粪。
為了實(shí)現(xiàn)這些需求，iOS 簽名的復(fù)雜度也就開(kāi)始增加了沧侥。
蘋果這里給出的方案是使用了雙層簽名可霎，會(huì)比較繞，流程大概是這樣的：
- 在你的 Mac 開(kāi)發(fā)機(jī)器生成一對(duì)公私鑰宴杀，這里稱為公鑰L癣朗，私鑰L。L:Local
- 蘋果自己有固定的一對(duì)公私鑰旺罢，跟上面 AppStore 例子一樣旷余，私鑰在蘋果后臺(tái)，公鑰在每個(gè) iOS 設(shè)備上扁达。這里稱為公鑰A正卧，私鑰A。A:Apple
- 把公鑰 L 傳到蘋果后臺(tái)罩驻，用蘋果后臺(tái)里的私鑰 A 去簽名公鑰 L穗酥。得到一份數(shù)據(jù)包含了公鑰 L 以及其簽名，把這份數(shù)據(jù)稱為證書。
- 在開(kāi)發(fā)時(shí)砾跃，編譯完一個(gè) APP 后骏啰，用本地的私鑰 L 對(duì)這個(gè) APP 進(jìn)行簽名，同時(shí)把第三步得到的證書一起打包進(jìn) APP 里抽高，安裝到手機(jī)上判耕。
- 在安裝時(shí)，iOS 系統(tǒng)取得證書翘骂，通過(guò)系統(tǒng)內(nèi)置的公鑰 A壁熄，去驗(yàn)證證書的數(shù)字簽名是否正確。
- 驗(yàn)證證書后確保了公鑰 L 是蘋果認(rèn)證過(guò)的碳竟，再用公鑰 L 去驗(yàn)證 APP 的簽名草丧，這里就間接驗(yàn)證了這個(gè) APP 安裝行為是否經(jīng)過(guò)蘋果官方允許。（這里只驗(yàn)證安裝行為莹桅，不驗(yàn)證APP 是否被改動(dòng)昌执，因?yàn)殚_(kāi)發(fā)階段 APP 內(nèi)容總是不斷變化的，蘋果不需要管诈泼。）
加點(diǎn)東西
上述流程只解決了上面第一個(gè)需求懂拾，也就是需要經(jīng)過(guò)蘋果允許才可以安裝，還未解決第二個(gè)避免被濫用的問(wèn)題铐达。怎么解決呢岖赋？蘋果再加了兩個(gè)限制，一是限制在蘋果后臺(tái)注冊(cè)過(guò)的設(shè)備才可以安裝瓮孙，二是限制簽名只能針對(duì)某一個(gè)具體的 APP唐断。
怎么加的？在上述第三步杭抠，蘋果用私鑰 A 簽名我們本地公鑰 L 時(shí)栗涂，實(shí)際上除了簽名公鑰 L，還可以加上無(wú)限多數(shù)據(jù)祈争，這些數(shù)據(jù)都可以保證是經(jīng)過(guò)蘋果官方認(rèn)證的，不會(huì)有被篡改的可能角寸。
可以想到把 允許安裝的設(shè)備 ID 列表 和 App對(duì)應(yīng)的 AppID 等數(shù)據(jù)菩混，都在第三步這里跟公鑰L一起組成證書，再用蘋果私鑰 A 對(duì)這個(gè)證書簽名扁藕。在最后第 5 步驗(yàn)證時(shí)就可以拿到設(shè)備 ID 列表沮峡，判斷當(dāng)前設(shè)備是否符合要求。根據(jù)數(shù)字簽名的原理亿柑，只要數(shù)字簽名通過(guò)驗(yàn)證邢疙，第 5 步這里的設(shè)備 IDs / AppID / 公鑰 L 就都是經(jīng)過(guò)蘋果認(rèn)證的，無(wú)法被修改，蘋果就可以限制可安裝的設(shè)備和 APP疟游，避免濫用呼畸。
最終流程
到這里這個(gè)證書已經(jīng)變得很復(fù)雜了，有很多額外信息颁虐，實(shí)際上除了 設(shè)備 ID / AppID蛮原，還有其他信息也需要在這里用蘋果簽名，像這個(gè) APP 里 iCloud / push / 后臺(tái)運(yùn)行 等權(quán)限蘋果都想控制另绩，蘋果把這些權(quán)限開(kāi)關(guān)統(tǒng)一稱為 Entitlements儒陨，它也需要通過(guò)簽名去授權(quán)。
實(shí)際上一個(gè)“證書”本來(lái)就有規(guī)定的格式規(guī)范笋籽，上面我們把各種額外信息塞入證書里是不合適的蹦漠，于是蘋果另外搞了個(gè)東西，叫 Provisioning Profile车海，一個(gè) Provisioning Profile 里就包含了證書以及上述提到的所有額外信息笛园，以及所有信息的簽名。
所以整個(gè)流程稍微變一下容劳，就變成這樣了：
因?yàn)椴襟E有小變動(dòng)喘沿，這里我們不辭啰嗦重新再列一遍整個(gè)流程：
- 在你的 Mac 開(kāi)發(fā)機(jī)器生成一對(duì)公私鑰，這里稱為公鑰L竭贩，私鑰L蚜印。L:Local
- 蘋果自己有固定的一對(duì)公私鑰，跟上面 AppStore 例子一樣留量，私鑰在蘋果后臺(tái)窄赋，公鑰在每個(gè) iOS 設(shè)備上。這里稱為公鑰A楼熄，私鑰A忆绰。A:Apple
- 把公鑰 L 傳到蘋果后臺(tái)，用蘋果后臺(tái)里的私鑰 A 去簽名公鑰 L可岂。得到一份數(shù)據(jù)包含了公鑰 L 以及其簽名错敢，把這份數(shù)據(jù)稱為證書。
- 在蘋果后臺(tái)申請(qǐng) AppID缕粹，配置好設(shè)備 ID 列表和 APP 可使用的權(quán)限稚茅，再加上第③步的證書，組成的數(shù)據(jù)用私鑰 A 簽名平斩，把數(shù)據(jù)和簽名一起組成一個(gè) Provisioning Profile 文件亚享，下載到本地 Mac 開(kāi)發(fā)機(jī)。
- 在開(kāi)發(fā)時(shí)绘面，編譯完一個(gè) APP 后欺税，用本地的私鑰 L 對(duì)這個(gè) APP 進(jìn)行簽名侈沪，同時(shí)把第④步得到的 Provisioning Profile 文件打包進(jìn) APP 里，文件名為 embedded.mobileprovision晚凿，把 APP 安裝到手機(jī)上亭罪。
- 在安裝時(shí)，iOS 系統(tǒng)取得證書晃虫，通過(guò)系統(tǒng)內(nèi)置的公鑰 A皆撩，去驗(yàn)證 embedded.mobileprovision 的數(shù)字簽名是否正確，里面的證書簽名也會(huì)再驗(yàn)一遍哲银。
- 確保了 embedded.mobileprovision 里的數(shù)據(jù)都是蘋果授權(quán)以后扛吞，就可以取出里面的數(shù)據(jù)，做各種驗(yàn)證荆责，包括用公鑰 L 驗(yàn)證APP簽名滥比，驗(yàn)證設(shè)備 ID 是否在 ID 列表上，AppID 是否對(duì)應(yīng)得上做院，權(quán)限開(kāi)關(guān)是否跟 APP 里的 Entitlements 對(duì)應(yīng)等盲泛。
開(kāi)發(fā)者證書從簽名到認(rèn)證最終蘋果采用的流程大致是這樣，還有一些細(xì)節(jié)像證書有效期/證書類型等就不細(xì)說(shuō)了键耕。
概念和操作
上面的步驟對(duì)應(yīng)到我們平常具體的操作和概念是這樣的：
- 第 1 步對(duì)應(yīng)的是 keychain 里的 “從證書頒發(fā)機(jī)構(gòu)請(qǐng)求證書”寺滚，這里就本地生成了一堆公私鑰，保存的 CertificateSigningRequest 就是公鑰屈雄，私鑰保存在本地電腦里村视。
- 第 2 步蘋果處理，不用管酒奶。
- 第 3 步對(duì)應(yīng)把 CertificateSigningRequest 傳到蘋果后臺(tái)生成證書蚁孔，并下載到本地。這時(shí)本地有兩個(gè)證書惋嚎，一個(gè)是第 1 步生成的杠氢，一個(gè)是這里下載回來(lái)的，keychain 會(huì)把這兩個(gè)證書關(guān)聯(lián)起來(lái)另伍，因?yàn)樗麄児借€是對(duì)應(yīng)的鼻百，在XCode選擇下載回來(lái)的證書時(shí)，實(shí)際上會(huì)找到 keychain 里對(duì)應(yīng)的私鑰去簽名摆尝。這里私鑰只有生成它的這臺(tái) Mac 有愕宋，如果別的 Mac 也要編譯簽名這個(gè) App 怎么辦？答案是把私鑰導(dǎo)出給其他 Mac 用结榄，在 keychain 里導(dǎo)出私鑰，就會(huì)存成 .p12 文件囤捻，其他 Mac 打開(kāi)后就導(dǎo)入了這個(gè)私鑰臼朗。
- 第 4 步都是在蘋果網(wǎng)站上操作，配置 AppID / 權(quán)限 / 設(shè)備等，最后下載 Provisioning Profile 文件视哑。
- 第 5 步 XCode 會(huì)通過(guò)第 3 步下載回來(lái)的證書（存著公鑰）绣否，在本地找到對(duì)應(yīng)的私鑰（第一步生成的），用本地私鑰去簽名 App挡毅，并把 Provisioning Profile 文件命名為 embedded.mobileprovision 一起打包進(jìn)去蒜撮。這里對(duì) App 的簽名數(shù)據(jù)保存分兩部分，Mach-O 可執(zhí)行文件會(huì)把簽名直接寫入這個(gè)文件里跪呈，其他資源文件則會(huì)保存在 _CodeSignature 目錄下段磨。
第 6 - 7 步的打包和驗(yàn)證都是 Xcode 和 iOS 系統(tǒng)自動(dòng)做的事。
這里再總結(jié)一下這些概念：
證書：內(nèi)容是公鑰或私鑰耗绿，由其他機(jī)構(gòu)對(duì)其簽名組成的數(shù)據(jù)包苹支。
Entitlements：包含了 App 權(quán)限開(kāi)關(guān)列表。
CertificateSigningRequest：本地公鑰误阻。
p12：本地私鑰债蜜，可以導(dǎo)入到其他電腦。
Provisioning Profile：包含了 證書 / Entitlements 等數(shù)據(jù)究反，并由蘋果后臺(tái)私鑰簽名的數(shù)據(jù)包寻定。
其他發(fā)布方式
前面以開(kāi)發(fā)包為例子說(shuō)了簽名和驗(yàn)證的流程，另外兩種方式 In-House 企業(yè)簽名和 AD-Hoc 流程也是差不多的精耐，只是企業(yè)簽名不限制安裝的設(shè)備數(shù)狼速，另外需要用戶在 iOS 系統(tǒng)設(shè)置上手動(dòng)點(diǎn)擊信任這個(gè)企業(yè)才能通過(guò)驗(yàn)證。
而 AppStore 的簽名驗(yàn)證方式有些不一樣黍氮，前面我們說(shuō)到最簡(jiǎn)單的簽名方式唐含，蘋果在后臺(tái)直接用私鑰簽名 App 就可以了，實(shí)際上蘋果確實(shí)是這樣做的沫浆，如果去下載一個(gè) AppStore 的安裝包捷枯，會(huì)發(fā)現(xiàn)它里面是沒(méi)有 embedded.mobileprovision 文件的，也就是它安裝和啟動(dòng)的流程是不依賴這個(gè)文件专执，驗(yàn)證流程也就跟上述幾種類型不一樣了淮捆。
據(jù)猜測(cè)，因?yàn)樯蟼鞯?AppStore 的包蘋果會(huì)重新對(duì)內(nèi)容加密本股，原來(lái)的本地私鑰簽名就沒(méi)有用了攀痊，需要重新簽名，從 AppStore 下載的包蘋果也并不打算控制它的有效期拄显，不需要內(nèi)置一個(gè) embedded.mobileprovision 去做校驗(yàn)苟径，直接在蘋果用后臺(tái)的私鑰重新簽名，iOS 安裝時(shí)用本地公鑰驗(yàn)證 App 簽名就可以了躬审。
那為什么發(fā)布 AppStore 的包還是要跟開(kāi)發(fā)版一樣搞各種證書和 Provisioning Profile棘街？猜測(cè)因?yàn)樘O果想做統(tǒng)一管理蟆盐，Provisioning Profile 里包含一些權(quán)限控制，AppID 的檢驗(yàn)等遭殉，蘋果不想在上傳 AppStore 包時(shí)重新用另一種協(xié)議做一遍這些驗(yàn)證石挂，就不如統(tǒng)一把這部分放在 Provisioning Profile 里，上傳 AppStore 時(shí)只要用同樣的流程驗(yàn)證這個(gè) Provisioning Profile 是否合法就可以了险污。
所以 App 上傳到 AppStore 后痹愚，就跟你的 證書 / Provisioning Profile 都沒(méi)有關(guān)系了，無(wú)論他們是否過(guò)期或被廢除蛔糯，都不會(huì)影響 AppStore 上的安裝包拯腮。
到這里 iOS 簽名機(jī)制的原理和主流程大致說(shuō)完了，希望能對(duì)理解蘋果簽名和排查日常簽名問(wèn)題有所幫助渤闷。
文章轉(zhuǎn)載出處:傳送門
