純粹就是總結，很多地方跟參考資料一樣，就是自己手動打一遍，自己親自畫個圖增加理解和加強記憶力，而不只是複製貼上
ios 打包流程也不在此敘述，相信很多人已經對照過各種**並茂的文章一一操作過
即加密金鑰與解密金鑰不同，且成對出現
對外公開的稱為公鑰，這對金鑰生成者才擁有的稱為私鑰
通過私鑰加密的密文只能通過公鑰解密，反之亦然
例如，rsa演算法，非對稱加密加解密比較耗時，實際使用中，往往與對稱加密和摘要演算法結合使用
經典用法
防止中間攻擊：接收方將公鑰公布-》傳送方通過該公鑰將明文加密-》傳輸給接收方-》接收方使用私鑰解密，通常用於交換對稱金鑰（由於非接收方無私鑰，無法截獲）
身份驗證和防止篡改：私鑰加密授權明文-》將明文+加密後的密文+公鑰一併傳送給接收方-》接收方用公鑰解密密文，再與明文對比是否一致，以此判斷是否被篡改，用於數字簽名
將任意長度文字通過乙個演算法得到乙個固定長度的文字。
源文字不同，計算結果必然不同
無法從結果反推源
例如，md5和sha演算法
非對稱加密與摘要演算法的結合
結合摘要演算法是因為非對稱加密的原理限制可加密的內容不能太大
數字簽名驗證過程
情景：有一段授權文字，需要發布，要防止中途篡改內容，保證完整性與合法性
傳送方：
1. 授權文字-》摘要演算法-》得到摘要
2. 私鑰加密摘要得到密文
3. 將源授權文字+密文+公鑰一併發布
驗證方：
1. 用公鑰解密密文得到摘要a
2. 將源授權文字-》摘要演算法-》得到摘要b
3. 對比摘要a與摘要b是否一致
當app 提交審核通過後，apple會對app重簽名，所以從app store**的app都是蘋果的官方簽名
流程如下：
apple 官方有自己固定的一對公鑰和私鑰，私鑰a存在apple後台，公鑰a存在ios裝置
app審核通過後，apple後台用私鑰a對其進行重簽名
app**到ios裝置後，ios裝置內建的公鑰a會對app的簽名進行驗證 如果驗證通過，則可執行，否則不能
當然除了這個方式，還有一下三種方式安裝乙個app：
1. 開發時，直接通過usb將應用安裝到手機進行除錯；
2. in-house 企業內部分發，可直接安裝企業證書簽名的app；
3. ad-hoc 相當於企業分發的限制版，限制安裝裝置數量。
對與開發除錯安裝app時，有兩個需求：
1. 安裝包無需上傳到apple伺服器；
2. 必須經過apple允許，且不能被濫用導致非開發app也能被安裝
流程如下：
在mac上生成一對公私鑰，分別為公鑰l，私鑰l
apple 官方有自己固定的一對公鑰和私鑰，私鑰a存在apple後台，公鑰a內建在ios裝置
把公鑰l 上傳apple後台，apple後台用私鑰a對公鑰l進行簽名，將得到的簽名+公鑰l打包起來，稱為證書 開發時，編譯完乙個app後，用本地私鑰l對app進行簽名，然後把3中的證書、app和app簽名一起打包安裝到手機上。 ios裝置內建的公鑰a對證書中簽名進行驗證 如果5中驗證通過，再用證書中的公鑰l對app簽名進行驗證，從而間接保證app安裝是官方允許的
上述流程只解決了需要apple允許才能安裝，但還未解決避免被濫用的問題。
在此，蘋果加了兩個限制，1.限制裝置，2.限制簽名只針對某一具體app。
流程基本如上，只是新增了裝置ids和appid：
第三步：把公鑰l 上傳apple後台，apple後台用私鑰a對(公鑰l+裝置ids+appid)進行簽名，將得到的簽名+公鑰l打包起來，成為證書
第五步：ios裝置內建的公鑰a對證書中簽名進行驗證，同時將裝置ids判斷當前裝置是否符合要求，appid驗證app是否一致
上述證書有很多額外資訊，實際上出了 裝置ids/appid，還是其他資訊，比如icloud／push／後台執行等許可權，這些許可權開關統稱為 entitlements，它也需要通過簽名去授權，這些額外資訊都塞在證書裡是不合適的，所以就有乙個叫provisioning profile的東西。
provisioning profile = 證書 + 上述額外資訊 + 所有資訊的簽名
最終流程如下：
在mac上生成一對公私鑰，分別為公鑰l，私鑰l
apple 官方有自己固定的一對公鑰和私鑰，私鑰a存在apple後台，公鑰a內建在ios裝置
把公鑰l 上傳apple後台，apple後台用私鑰a對公鑰l進行簽名，將得到的簽名+公鑰l打包起來，稱為證書 在蘋果後台申請appid，配置好裝置ids, entitlements,這些額外資訊+3中的證書組成的資料用私鑰a簽名，最後證書+額外資訊+簽名組成 provisioning profile 檔案，**到mac本地 開發時，編譯完乙個app後，用本地私鑰l對app進行簽名，然後把4中的provisioning profile檔案打包進app裡，檔名為embedded.mobileprovision，安裝到手機上。 安裝時，ios裝置內建的公鑰a對embedded.mobileprovision的數字簽名進行驗證，同時對裡面的證書的簽名也會驗證 如果6中驗證通過，確保了embedded.mobileprovision的資料是蘋果授權後，再取出裡面資料做各種驗證，包括公鑰l對app簽名進行驗證，驗證裝置id，appid，許可權開關
上述步驟與平常具體操作與概念如下：
keychain 裡的「從證書頒發機構請求證書」，本地生成一對公私鑰，儲存的certificatesigningrequest(csr)即公鑰l，私鑰l儲存在電腦本地
蘋果處理
在member center把certificatesigningrequest上傳到蘋果後台生成證書，**到本地（因為私鑰是本地mac持有，所以團隊開發時，可在keychain匯出私鑰，存為.p12檔案，其他mac即可匯入這個私鑰） 在member center配置appid／裝置uuid／entitlements, 生成對應的 provisioning profile 檔案，並**到本地
打包編譯時，xcode會根據3中的證書，用對應該證書的本地私鑰l對app進行簽名，並把4中的 provisioning profile 檔案命名為 embedded.mobileprovision 一起打包進去。這裡對app的簽名資料分兩部分，mach-o 可執行檔案把簽名直接寫進這個檔案，其他資源檔案則儲存在_codesignature目錄下
6到7的打包驗證是xcode和ios的事
其他發布方式（in-house和ad-hoc）流程與開發包簽名驗證流程差不多，in-house不限制安裝的裝置數
iOS 簽名機制與證書
純粹就是總結，很多地方跟參考資料一樣，就是自己手動打一遍，自己親自畫個圖增加理解和加強記憶力，而不只是複製貼上 ios 打包流程也不在此敘述，相信很多人已經對照過各種 並茂的文章一一操作過 即加密金鑰與解密金鑰不同，且成對出現 對外公開的稱為公鑰，這對金鑰生成者才擁有的稱為私鑰 通過私鑰加密的密文只...
漫談iOS程式的證書和簽名機制
6 天前 發布 原文 漫談ios程式的證書和簽名機制 接觸ios開發半年，曾經也被這個主題坑的摸不著頭腦，也在 上買過企業證書簽名這些服務，有大神都做了乙個全自動的發布打包 不過此大神現在不賣企業證書了 甚是羨慕和崇拜。於是，花了一點時間去研究了一下ios這套證書和簽名機制，並撰文分享給需要的朋友。...
iOS 簽名機制
上述的 n,e 這兩個資料在一起就是公鑰，n,d 這兩個資料就是私鑰，滿足用私鑰加密，公鑰解密，或反過來公鑰加密，私鑰解密，也滿足在只暴露公鑰 只知道 n 和 e 的情況下，要推導出私鑰 n,d 需要把大整數 n 因數分解。目前因數分解只能靠暴力窮舉，而 n 數字越大，越難以用窮舉計算出因數 p 和...