iOS 簽名機制挺復雜替饿，各種證書盛垦，Provisioning Profile腾夯，entitlements，CertificateSigningRequest班利，p12罗标，AppID闯割，概念一堆竿拆，也很容易出錯丙笋，本文嘗試從原理出發(fā)御板，一步步推出為什么會有這么多概念，希望能有助于理解 iOS App 簽名的原理和流程敬鬓。
一: 目的
二: 非對稱加密
三: 數(shù)字簽名
四:最簡單的簽名
五: 新的需求
六: 防止濫用
七: 最終流程
八: 概念和操作
九: 其他發(fā)布方式
十： P.S.一些疑問
一： 目的
先來看看蘋果的簽名機制是為了做什么列林。在 iOS 出來之前希痴，在主流操作系統(tǒng)(Mac/Windows/Linux)上開發(fā)和運行軟件是不需要簽名的砌创，軟件隨便從哪里下載都能運行嫩实，導致平臺對第三方軟件難以控制窥岩，盜版流行颂翼。蘋果希望解決這樣的問題，在 iOS 平臺對第三方 APP 有絕對的控制權球及，一定要保證每一個安裝到 iOS 上的 APP 都是經過蘋果官方允許的吃引，怎樣保證呢？就是通過簽名機制朦佩。
二： 非對稱加密
通常我們說的簽名就是數(shù)字簽名语稠，它是基于非對稱加密算法實現(xiàn)的。對稱加密是通過同一份密鑰加密和解密數(shù)據输枯，而非對稱加密則有兩份密鑰占贫，分別是公鑰和私鑰型奥，用公鑰加密的數(shù)據厢汹，要用私鑰才能解密，用私鑰加密的數(shù)據界弧，要用公鑰才能解密垢箕。
簡單說一下常用的非對稱加密算法 RSA 的數(shù)學原理条获，理解簡單的數(shù)學原理帅掘，就可以理解非對稱加密是怎么做到的，為什么會是安全的：
- 1： 選兩個質數(shù) p 和 q素标，相乘得出一個大整數(shù)n萍悴，例如 p=61癣诱，q=53撕予，n=pq=3233
- 2： 選 1-n 間的隨便一個質數(shù) e，例如 e = 17
- 3： 經過一系列數(shù)學公式欠母，算出一個數(shù)字 d赏淌，滿足：
- a: 通過 n 和 e 這兩個數(shù)據一組數(shù)據進行數(shù)學運算后六水，可以通過 n 和 d 去反解運算掷贾，反過來也可以荣茫。
- b: 如果只知道 n 和 e啡莉，要推導出 d票罐，需要知道 p 和 q，也就是要需要把 n 因數(shù)分解疗杉。
上述的 (n,e) 這兩個數(shù)據在一起就是公鑰烟具，(n,d) 這兩個數(shù)據就是私鑰朝聋，滿足用公鑰加密冀痕，私鑰解密，或反過來公鑰加密僻他，私鑰解密吨拗，也滿足在只暴露公鑰（只知道 n 和 e）的情況下劝篷，要推導出私鑰 (n,d)娇妓，需要把大整數(shù) n 因數(shù)分解勘高。目前因數(shù)分解只能靠暴力窮舉华望，而n數(shù)字越大赖舟，越難以用窮舉計算出因數(shù) p 和 q夸楣，也就越安全豫喧，當 n 大到二進制 1024 位或 2048 位時紧显，以目前技術要破解幾乎不可能，所以非常安全涉兽。
若對數(shù)字 d 是怎樣計算出來的感興趣枷畏，可以詳讀這兩篇文章：RSA 算法原理（一）（二）
三： 數(shù)字簽名
現(xiàn)在知道了有非對稱加密這東西，那數(shù)字簽名是怎么回事呢触趴？
數(shù)字簽名的作用是我對某一份數(shù)據打個標記雕蔽，表示我認可了這份數(shù)據（簽了個名）批狐，然后我發(fā)送給其他人嚣艇，其他人可以知道這份數(shù)據是經過我認證的华弓，數(shù)據沒有被篡改過寂屏。
有了上述非對稱加密算法迁霎，就可以實現(xiàn)這個需求：
[圖片上傳失敗...(image-7e68f9-1517050274707)]
- 1: 首先用一種算法，算出原始數(shù)據的摘要秘豹。需滿足 a.若原始數(shù)據有任何變化既绕，計算出來的摘要值都會變化凄贩。 b.摘要要夠短疲扎。這里最常用的算法是MD5评肆。
- 2: 生成一份非對稱加密的公鑰和私鑰，私鑰我自己拿著盹廷，公鑰公布出去俄占。
- 3: 對一份數(shù)據缸榄，算出摘要后甚带，用私鑰加密這個摘要佳头，得到一份加密后的數(shù)據康嘉，稱為原始數(shù)據的簽名。把它跟原始數(shù)據一起發(fā)送給用戶敷钾。
- 4: 用戶收到數(shù)據和簽名后阻荒，用公鑰解密得到摘要财松。同時用戶用同樣的算法計算原始數(shù)據的摘要纱控，對比這里計算出來的摘要和用公鑰解密簽名得到的摘要是否相等甜害，若相等則表示這份數(shù)據中途沒有被篡改過尔店，因為如果篡改過嚣州，摘要會變化。
之所以要有第一步計算摘要情竹，是因為非對稱加密的原理限制可加密的內容不能太大（不能大于上述 n 的位數(shù)秦效，也就是一般不能大于 1024 位/ 2048 位）阱州，于是若要對任意大的數(shù)據簽名，就需要改成對它的特征值簽名苔货，效果是一樣的蒲赂。
好了刁憋，有了非對稱加密的基礎至耻，知道了數(shù)字簽名是什么尘颓，怎樣可以保證一份數(shù)據是經過某個地方認證的疤苹，來看看怎樣通過數(shù)字簽名的機制保證每一個安裝到 iOS 上的 APP 都是經過蘋果認證允許的。
四： 最簡單的簽名
要實現(xiàn)這個需求很簡單惫皱，最直接的方式旅敷，蘋果官方生成一對公私鑰颤霎，在 iOS 里內置一個公鑰涂滴，私鑰由蘋果后臺保存柔纵，我們傳 App 上 AppStore 時首量，蘋果后臺用私鑰對 APP 數(shù)據進行簽名加缘，iOS 系統(tǒng)下載這個 APP 后拣宏，用公鑰驗證這個簽名杠人，若簽名正確，這個 APP 肯定是由蘋果后臺認證的辑莫，并且沒有被修改過各吨，也就達到了蘋果的需求：保證安裝的每一個 APP 都是經過蘋果官方允許的揭蜒。
[圖片上傳失敗...(image-771fcc-1517050274707)]
如果我們 iOS 設備安裝 APP 只有從 AppStore 下載這一種方式的話屉更，這件事就結束了洒缀，沒有任何復雜的東西，只有一個數(shù)字簽名萨脑，非常簡單地解決問題葱峡。
但實際上因為除了從 AppStore 下載砰奕，我們還可以有三種方式安裝一個 App：
- 開發(fā) App 時可以直接把開發(fā)中的應用安裝進手機進行調試。
- In-House 企業(yè)內部分發(fā)仅淑，可以直接安裝企業(yè)證書簽名后的 APP胸哥。
- AD-Hoc 相當于企業(yè)分發(fā)的限制版空厌，限制安裝設備數(shù)量，較少用
蘋果要對用這三種方式安裝的 App 進行控制筐钟，就有了新的需求篓冲，無法像上面這樣簡單了宠哄。
五： 新的需求
我們先來看第一個诽俯，開發(fā)時安裝APP惊畏，它有兩個個需求：
- 1： 安裝包不需要傳到蘋果服務器密任，可以直接安裝到手機上浪讳。如果你編譯一個 APP 到手機前要先傳到蘋果服務器簽名淹遵，這顯然是不能接受的。
- 2： 蘋果必須對這里的安裝有控制權济炎，包括
- a.經過蘋果允許才可以這樣安裝须尚。
- b.不能被濫用導致非開發(fā)app也能被安裝耐床。
為了實現(xiàn)這些需求撩轰，iOS 簽名的復雜度也就開始增加了堪嫂。
蘋果這里給出的方案是使用了雙層簽名，會比較繞镜廉，流程大概是這樣的：
- 1: 在你的 Mac 開發(fā)機器生成一對公私鑰娇唯，這里稱為公鑰L塔插，私鑰L想许。L:Local
- 2: 蘋果自己有固定的一對公私鑰流纹，跟上面 AppStore 例子一樣漱凝，私鑰在蘋果后臺诸迟，公鑰在每個 iOS 設備上阵苇。這里稱為公鑰A绅项，私鑰A快耿。A:Apple
- 3: 把公鑰 L 傳到蘋果后臺，用蘋果后臺里的私鑰 A 去簽名公鑰 L示括。得到一份數(shù)據包含了公鑰 L 以及其簽名痢畜，把這份數(shù)據稱為證書丁稀。
- 4: 在開發(fā)時线衫，編譯完一個 APP 后，用本地的私鑰 L 對這個 APP 進行簽名白热，同時把第三步得到的證書一起打包進 APP 里粗卜，安裝到手機上屋确。
- 5: 在安裝時，iOS 系統(tǒng)取得證書续扔，通過系統(tǒng)內置的公鑰 A攻臀，去驗證證書的數(shù)字簽名是否正確。
- 6: 驗證證書后確保了公鑰 L 是蘋果認證過的纱昧，再用公鑰 L 去驗證 APP 的簽名刨啸，這里就間接驗證了這個 APP 安裝行為是否經過蘋果官方允許。（這里只驗證安裝行為识脆，不驗證APP 是否被改動呜投，因為開發(fā)階段 APP 內容總是不斷變化的，蘋果不需要管存璃。）
六：防止濫用
上述流程只解決了上面第一個需求粘招，也就是需要經過蘋果允許才可以安裝，還未解決第二個避免被濫用的問題磷醋。怎么解決呢煌恢？蘋果再加了兩個限制你雌，一是限制在蘋果后臺注冊過的設備才可以安裝氓栈，二是限制簽名只能針對某一個具體的 APP。
怎么加的？在上述第三步氯葬，蘋果用私鑰 A 簽名我們本地公鑰 L 時闯睹，實際上除了簽名公鑰 L，還可以加上無限多數(shù)據，這些數(shù)據都可以保證是經過蘋果官方認證的浇垦，不會有被篡改的可能垦沉。
[圖片上傳失敗...(image-3bdcf8-1517050920757)]
可以想到把 允許安裝的設備 ID 列表 和 App對應的 AppID 等數(shù)據贩疙，都在第三步這里跟公鑰L一起組成證書，再用蘋果私鑰 A 對這個證書簽名臭胜。在最后第 5 步驗證時就可以拿到設備 ID 列表仪壮，判斷當前設備是否符合要求养盗。根據數(shù)字簽名的原理，只要數(shù)字簽名通過驗證蝶缀，第 5 步這里的設備 IDs / AppID / 公鑰 L 就都是經過蘋果認證的，無法被修改，蘋果就可以限制可安裝的設備和 APP藏研，避免濫用业踏。
七：最終流程
到這里這個證書已經變得很復雜了伐脖，有很多額外信息巫俺，實際上除了 設備 ID / AppID嘹承，還有其他信息也需要在這里用蘋果簽名，像這個 APP 里 iCloud / push / 后臺運行 等權限蘋果都想控制蒙揣，蘋果把這些權限開關統(tǒng)一稱為 Entitlements，它也需要通過簽名去授權递宅。
實際上一個“證書”本來就有規(guī)定的格式規(guī)范，上面我們把各種額外信息塞入證書里是不合適的，于是蘋果另外搞了個東西撩银，叫 Provisioning Profile，一個 Provisioning Profile 里就包含了證書以及上述提到的所有額外信息，以及所有信息的簽名。
//[圖片上傳失敗...(image-d82e66-1517051011579)]
因為步驟有小變動楔绞，這里我們不辭啰嗦重新再列一遍整個流程：
- 1: 在你的 Mac 開發(fā)機器生成一對公私鑰，這里稱為公鑰L，私鑰L钦讳。L:Local
- 2: 蘋果自己有固定的一對公私鑰，跟上面 AppStore 例子一樣，私鑰在蘋果后臺飞主，公鑰在每個 -
iOS 設備上牡拇。這里稱為公鑰A，私鑰A。A:Apple - 3: 把公鑰 L 傳到蘋果后臺第焰，用蘋果后臺里的私鑰 A 去簽名公鑰 L液荸。得到一份數(shù)據包含了公鑰 L 以及其簽名，把這份數(shù)據稱為證書常挚。
- 4: 在蘋果后臺申請 AppID，配置好設備 ID 列表和 APP 可使用的權限斤葱，再加上第③步的證書贮泞，組成的數(shù)據用私鑰 A 簽名珠叔，把數(shù)據和簽名一起組成一個 Provisioning Profile 文件，下載到本地 Mac 開發(fā)機血筑。
-5: 在開發(fā)時表伦，編譯完一個 APP 后，用本地的私鑰 L 對這個 APP 進行簽名，同時把第④步得到的 Provisioning Profile 文件打包進 APP 里竹祷，文件名為 embedded.mobileprovision，把 APP 安裝到手機上赖淤。 - 6: 在安裝時，iOS 系統(tǒng)取得證書基公，通過系統(tǒng)內置的公鑰 A斑司，去驗證 embedded.mobileprovision 的數(shù)字簽名是否正確磕潮，里面的證書簽名也會再驗一遍戏罢。
- 7: 確保了 embedded.mobileprovision 里的數(shù)據都是蘋果授權以后，就可以取出里面的數(shù)據阶淘，做各種驗證宛瞄，包括用公鑰 L 驗證APP簽名轩猩，驗證設備 ID 是否在 ID 列表上焦影，AppID 是否對應得上闸氮，權限開關是否跟 APP 里的 Entitlements 對應等该贾。
開發(fā)者證書從簽名到認證最終蘋果采用的流程大致是這樣举庶，還有一些細節(jié)像證書有效期/證書類型等就不細說了替梨。
八: 概念和操作
上面的步驟對應到我們平常具體的操作和概念是這樣的：
第 1 步對應的是 keychain 里的 “從證書頒發(fā)機構請求證書”铜幽，這里就本地生成了一堆公私鑰串稀，保存的 CertificateSigningRequest 就是公鑰，私鑰保存在本地電腦里盔夜。
第 2 步蘋果處理妥泉，不用管瓢剿。
第 3 步對應把
CertificateSigningRequest傳到蘋果后臺生成證書忙菠，并下載到本地。這時本地有兩個證書，一個是第 1 步生成的捆姜，一個是這里下載回來的传趾，keychain會把這兩個證書關聯(lián)起來，因為他們公私鑰是對應的泥技，在XCode選擇下載回來的證書時浆兰，實際上會找到 keychain 里對應的私鑰去簽名磕仅。這里私鑰只有生成它的這臺 Mac 有，如果別的 Mac 也要編譯簽名這個 App 怎么辦簸呈？答案是把私鑰導出給其他 Mac 用榕订，在keychain里導出私鑰，就會存成 .p12 文件蜕便，其他 Mac 打開后就導入了這個私鑰劫恒。第 4 步都是在蘋果網站上操作，配置 AppID / 權限 / 設備等轿腺，最后下載 Provisioning Profile 文件两嘴。
第 5 步 XCode 會通過第 3 步下載回來的證書（存著公鑰），在本地找到對應的私鑰（第一步生成的）族壳，用本地私鑰去簽名 App憔辫，并把 Provisioning Profile 文件命名為
embedded.mobileprovision一起打包進去。這里對 App 的簽名數(shù)據保存分兩部分仿荆，Mach-O 可執(zhí)行文件會把簽名直接寫入這個文件里拢操，其他資源文件則會保存在_CodeSignature目錄下。第 6 - 7 步的打包和驗證都是 Xcode 和 iOS 系統(tǒng)自動做的事杠园。
這里再總結一下這些概念：
- 證書：內容是公鑰或私鑰返劲，由其他機構對其簽名組成的數(shù)據包篮绿。
- Entitlements：包含了 App 權限開關列表亲配。
- CertificateSigningRequest：本地公鑰惶凝。
- p12：本地私鑰苍鲜，可以導入到其他電腦。
- Provisioning Profile：包含了 證書 / Entitlements 等數(shù)據洒疚，并由蘋果后臺私鑰簽名的數(shù)據包。
九： 其他發(fā)布方式
前面以開發(fā)包為例子說了簽名和驗證的流程巍扛，另外兩種方式 In-House 企業(yè)簽名和 AD-Hoc 流程也是差不多的撤奸，只是企業(yè)簽名不限制安裝的設備數(shù)喊括，另外需要用戶在 iOS 系統(tǒng)設置上手動點擊信任這個企業(yè)才能通過驗證瘾晃。
而 AppStore 的簽名驗證方式有些不一樣，前面我們說到最簡單的簽名方式，蘋果在后臺直接用私鑰簽名 App 就可以了肉津，實際上蘋果確實是這樣做的妹沙，如果去下載一個 AppStore 的安裝包，會發(fā)現(xiàn)它里面是沒有 embedded.mobileprovision 文件的玄窝，也就是它安裝和啟動的流程是不依賴這個文件恩脂，驗證流程也就跟上述幾種類型不一樣了俩块。
據猜測浓领，因為上傳到 AppStore 的包蘋果會重新對內容加密，原來的本地私鑰簽名就沒有用了漫仆，需要重新簽名盲厌，從 AppStore 下載的包蘋果也并不打算控制它的有效期，不需要內置一個 embedded.mobileprovision 去做校驗狸眼，直接在蘋果用后臺的私鑰重新簽名拓萌，iOS 安裝時用本地公鑰驗證 App 簽名就可以了微王。
那為什么發(fā)布 AppStore 的包還是要跟開發(fā)版一樣搞各種證書和 Provisioning Profile炕倘？猜測因為蘋果想做統(tǒng)一管理，Provisioning Profile 里包含一些權限控制啊央，AppID 的檢驗等瓜饥，蘋果不想在上傳 AppStore 包時重新用另一種協(xié)議做一遍這些驗證浴骂，就不如統(tǒng)一把這部分放在 Provisioning Profile 里，上傳 AppStore 時只要用同樣的流程驗證這個 Provisioning Profile 是否合法就可以了趣苏。
所以 App 上傳到 AppStore 后食磕，就跟你的 證書 / Provisioning Profile 都沒有關系了芬为，無論他們是否過期或被廢除蟀悦，都不會影響 AppStore 上的安裝包日戈。
到這里 iOS 簽名機制的原理和主流程大致說完了浙炼，希望能對理解蘋果簽名和排查日常簽名問題有所幫助唯袄。
十： P.S.一些疑問
1： 企業(yè)證書
企業(yè)證書簽名因為限制少恋拷，在國內被廣泛用于測試和盜版厅缺，fir.im / 蒲公英等測試平臺都是通過企業(yè)證書分發(fā)，國內一些市場像 PP 助手诀豁，愛思助手舷胜，一部分安裝手段也是通過企業(yè)證書重簽名活翩。通過企業(yè)證書簽名安裝的 App材泄，啟動時都會驗證證書的有效期脸爱，并且不定期請求蘋果服務器看證書是否被吊銷簿废，若已過期或被吊銷族檬，就會無法啟動 App化戳。對于這種助手的盜版安裝手段点楼，蘋果想打擊只能一個個吊銷企業(yè)證書掠廓，并沒有太好的辦法。
這里我的疑問是沉颂，蘋果做了那么多簽名和驗證機制去限制在 iOS 安裝 App铸屉，為什么又要出這樣一個限制很少的方式讓盜版鉆空子呢彻坛？若真的是企業(yè)用途不適合上 AppStore小压，也完全可以在 AppStore 開辟一個小的私密版塊，還是通過 AppStore 去安裝仪搔，就不會有這個問題了烤咧。
2： AppStore 加密
另一個問題是我們把 App 傳上 AppStore 后煮嫌，蘋果會對 App 進行加密抱虐，導致 App 體積增大不少，這個加密實際上是沒卵用的懦冰，只是讓破解的人要多做一個步驟刷钢，運行 App 去內存 dump 出可執(zhí)行文件而已内地，無論怎樣加密阱缓，都可以用這種方式拿出加密前的可執(zhí)行文件茬祷。所以為什么要做這樣的加密呢祭犯？想不到有什么好處粥惧。
3： 本地私鑰
我們看到前面說的簽名流程很繞很復雜突雪，經常出現(xiàn)各種問題涡贱，像有 Provisioning Profile 文件但證書又不對问词，本地有公鑰證書沒對應私鑰等情況，不理解原理的情況下會被繞暈辰狡，我的疑問是宛篇，這里為什么不能簡化呢叫倍？還是以開發(fā)證書為例段标，為什么一定要用本地 Mac 生成的私鑰去簽名？蘋果要的只是本地簽名炉奴，私鑰不一定是要本地生成的，蘋果也可以自己生成一對公私鑰給我們蛇更，放在 Provisioning Profile 里瞻赶，我們用里面的私鑰去加密就行了，這樣就不會有 CertificateSigningRequest 和 p12 的概念派任，跟本地 keychain 沒有關系砸逊，不需要關心證書，只要有 Provisioning Profile 就能簽名掌逛，流程會減少师逸，易用性會提高很多，同時蘋果想要的控制一點都不會少豆混，也沒有什么安全問題篓像，為什么不這樣設計呢？
能想到的一個原因是 Provisioning Profile 在非 AppStore 安裝時會打包進安裝包丹皱，第三方拿到這個 Provisioning Profile 文件就能直接用起來給他自己的 App 簽名了杰赛。但這種問題也挺好解決，只需要打包時去掉文件里的私鑰就行了，所以仍不明白為什么這樣設計忘苛。
本文出處 [ WeRead團隊博客]的iOS App 簽名的原理
