iOS 認證簽名知識點介紹，ios認證簽名知識點

iOS 認證簽名知識點介紹，ios認證簽名知識點

之前面試了很多 iOS 開發工程師，項目做的還可以，但是當聊起認證和簽名這些的時候，沒有幾個能說的頭頭是道。作為一個iOS 開發工程師，每當你配置各種認證忙的焦頭爛額的時候，有沒有想過這 TM 到底是為了啥？本文就告訴你這TM 的是為了啥！

Why ?

玩兒蘋果的都知道，通常情況下我們喜歡的 APP 是從 AppStore 上下載的。但是，蘋果希望在 iOS 平台對第三方 APP 有絕對的控制權，一定要保證每一個安裝到 iOS 上的 APP 都是經過蘋果官方允許的，怎樣保證呢？就是通過簽名機制。

非對稱式加密

通常我們說的簽名就是數位簽章，它是基於非對稱式加密演算法實現的。對稱式加密是通過同一份祕密金鑰加密和解密資料，而非對稱式加密則有兩份密鑰，分別是公開金鑰和私密金鑰，用公開金鑰加密的資料，要用私密金鑰才能解密，用私密金鑰加密的資料，要用公開金鑰才能解密。

簡單說一下常用的非對稱式加密演算法 RSA 的數學原理，理解簡單的數學原理，就可以理解非對稱式加密是怎麼做到的，為什麼會是安全的：

選兩個質數p和q，相乘得出一個大整數n，例如 p=61，q=53，n=pq=3233

選 1-n 間的隨便一個質數e，例如 e = 17

經過一系列數學公式，算出一個數字d，滿足：

a. 通過n和e這兩個資料一組資料進行數學運算後，可以通過 n 和 d 去反解運算，反過來也可以。

b. 如果只知道n和e，要推匯出d，需要知道p和q，也就是要需要把 n 因數分解。

上述的(n,e)這兩個資料在一起就是公開金鑰，(n,d)這兩個資料就是私密金鑰，滿足用私密金鑰加密，公開金鑰解密，或反過來公開金鑰加密，私密金鑰解密，也滿足在只暴露公開金鑰（只知道n和 e）的情況下，要推匯出私密金鑰(n,d)，需要把大整數n因數分解。目前因數分解只能靠暴力窮舉，而n數字越大，越難以用窮舉計算出因數p和q，也就越安全，當n大到二進位 1024 位或 2048 位時，以目前技術要破解幾乎不可能，所以非常安全。

數位簽章

很多文章都與現實生活中的證件蓋章做比喻，我認為不太恰當，容易誤導初學者。資料的世界裡，不可能像現實生活中那樣簡單。現在咱們一步一步分析什麼是數位簽章。
時間：某年某月某日
地點：地球任意有電腦的地方
人物：隔壁老王、東北老鐵
事件：隔壁老王要給東北老鐵發一個檔案(O)。
經過：隔壁老王有一台電腦，這台電腦能夠產生一對公開金鑰和私密金鑰。隔壁老王首先將檔案(O)用摘要演算法進行摘要，組建檔案摘要(M)。然後用私密金鑰對檔案摘要(M)進行加密，也就是數位簽章（以後統稱為“簽名”），產生一個簽名檔案(S)。然後隔壁老王將檔案（O）、簽名檔案（S）、公開金鑰一起發給了東北老鐵。

東北老鐵拿到這三樣東西後，首先用公開金鑰對簽名檔案(S)進行解密，組建檔案摘要（m）,然後用同樣的摘要演算法對檔案(O)摘要，組建檔案摘要(M)。東北老鐵只需要對比 m 和 M 是否一樣，就知道這個檔案有沒有被其他人改動。這就是數字加密的用途。

的理解：
1.首先用一種演算法，算出未經處理資料的摘要。需滿足 a.若未經處理資料有任何變化，計算出來的摘要值都會變化。 b.摘要要夠短。這裡最常用的演算法是MD5。

2.產生一份非對稱式加密的公開金鑰和私密金鑰，私密金鑰我自己拿著，公開金鑰公布出去。

3.對一份資料，算出摘要後，用私密金鑰加密這個摘要，得到一份加密後的資料，稱為未經處理資料的簽名。把它跟未經處理資料一起發送給使用者。

4.使用者收到資料和簽名後，用公開金鑰解密得到摘要。同時使用者用同樣的演算法計算未經處理資料的摘要，對比這裡計算出來的摘要和用公開金鑰解密簽名得到的摘要是否相等，若相等則表示這份資料中途沒有被篡改過，因為如果篡改過，摘要會變化。

從 AppStore 下載 APP

說明的就是，蘋果官方產生一對公私密金鑰，在 iOS 裡內建一個公開金鑰，私密金鑰由蘋果後台儲存，我們傳 App 上 AppStore 時，蘋果後台用私密金鑰對 APP 資料進行簽名，iOS 系統下載這個 APP 後，用公開金鑰驗證這個簽名，若簽名正確，這個 APP 肯定是由蘋果後台認證的，並且沒有被修改過，也就達到了蘋果的需求：保證安裝的每一個 APP 都是經過蘋果官方允許的。

從其他途徑安裝 app

事情沒有那麼簡單，實際上因為除了從 AppStore 下載，我們還可以有三種方式安裝一個 App：

1.開發 App 時可以直接把開發中的應用安裝進手機進行調試。

2.In-House 企業內部分發，可以直接安裝企業認證簽名後的 APP。

3.AD-Hoc 相當於企業分發的限制版，限制安裝裝置數量，較少用。

蘋果要對用這三種方式安裝的 App 進行控制，就有了新的需求，無法像上面這樣簡單了。

蘋果的方案是雙層簽名，如下：
1.在你的 Mac 開發機器產生一對公私密金鑰，這裡稱為公開金鑰L，私密金鑰L。L:Local

2.蘋果自己有固定的一對公私密金鑰，跟上面 AppStore 例子一樣，私密金鑰在蘋果後台，公開金鑰在每個 iOS 裝置上。這裡稱為公開金鑰A，私密金鑰A。A:Apple

3.把公開金鑰 L 傳到蘋果後台，用蘋果後台裡的私密金鑰 A 去簽名公開金鑰 L。得到一份資料包含了公開金鑰 L 以及其簽名，把這份資料稱為認證。

4.在開發時，編譯完一個 APP 後，用本地的私密金鑰 L 對這個 APP 進行簽名，同時把第三步得到的認證一起打包進 APP 裡，安裝到手機上。

5.在安裝時，iOS 系統取得認證，通過系統內建的公開金鑰 A，去驗證認證的數位簽章是否正確。

6.驗證認證後確保了公開金鑰 L 是蘋果認證過的，再用公開金鑰 L 去驗證 APP 的簽名，這裡就間接驗證了這個 APP 安裝行為是否經過蘋果官方允許。（這裡只驗證安裝行為，不驗證APP 是否被改動，因為開發階段 APP 內容總是不斷變化的，蘋果不需要管。）

限制安裝裝置，限制 APP

上述流程只解決了上面第一個需求，也就是需要經過蘋果允許才可以安裝，還未解決第二個避免被濫用的問題。怎麼解決呢？蘋果再加了兩個限制，一是限制在蘋果後台註冊過的裝置才可以安裝，二是限制簽名只能針對某一個具體的 APP。

可以想到把 允許安裝的裝置識別碼 列表 和 App對應的 AppID 等資料，都在第三步這裡跟公開金鑰L一起組成認證，再用蘋果私密金鑰 A 對這個認證簽名。在最後第 5 步驗證時就可以拿到裝置識別碼 列表，判斷當前裝置是否符合要求。根據數位簽章的原理，只要數位簽章通過驗證，第 5 步這裡的裝置識別碼s / AppID / 公開金鑰 L 就都是經過蘋果認證的，無法被修改，蘋果就可以限制可安裝的裝置和 APP，避免濫用。

到這裡這個認證已經變得很複雜了，有很多額外資訊，實際上除了 裝置識別碼 / AppID，還有其他資訊也需要在這裡用蘋果簽名，像這個 APP 裡 iCloud / push / 後台運行 等許可權蘋果都想控制，蘋果把這些許可權開關統一稱為 Enments，它也需要通過簽名去授權。

限制功能，比如推送

因為步驟有小變動，這裡我們不辭囉嗦重新再列一遍整個流程：

1.在你的 Mac 開發機器產生一對公私密金鑰，這裡稱為公開金鑰L，私密金鑰L。L:Local

2.蘋果自己有固定的一對公私密金鑰，跟上面 AppStore 例子一樣，私密金鑰在蘋果後台，公開金鑰在每個 iOS 裝置上。這裡稱為公開金鑰A，私密金鑰A。A:Apple

3.把公開金鑰 L 傳到蘋果後台，用蘋果後台裡的私密金鑰 A 去簽名公開金鑰 L。得到一份資料包含了公開金鑰 L 以及其簽名，把這份資料稱為認證。

4.在蘋果後台申請 AppID，配置好裝置識別碼 列表和 APP 可使用的許可權，再加上第③步的認證，組成的資料用私密金鑰 A 簽名，把資料和簽名一起組成一個 Provisioning Profile 檔案，下載到本地 Mac 開發機。

5.在開發時，編譯完一個 APP 後，用本地的私密金鑰 L 對這個 APP 進行簽名，同時把第④步得到的 Provisioning Profile 檔案打包進 APP 裡，檔案名稱為embedded.mobileprovision，把 APP 安裝到手機上。

6.在安裝時，iOS 系統取得認證，通過系統內建的公開金鑰 A，去驗證embedded.mobileprovision的數位簽章是否正確，裡面的認證簽名也會再驗一遍。

7.確保了embedded.mobileprovision裡的資料都是蘋果授權以後，就可以取出裡面的資料，做各種驗證，包括用公開金鑰 L 驗證APP簽名，驗證裝置識別碼 是否在 ID 列表上，AppID 是否對應得上，許可權開關是否跟 APP 裡的 Enments 對應等。

從憑證授權單位請求認證

鑰匙串程式中，從憑證授權單位請求認證的過程，就是在電腦上產生一對公開金鑰和私密金鑰，檔案CertificateSigningRequest裡面儲存的就是公開金鑰。

認證

從蘋果開發人員平台下載到本地的認證，裡面的內容就是公開金鑰或私密金鑰，由其他機構對其簽名組成的資料包。

描述檔案

Provisioning Profile，包含了 認證 / Enments 等資料，並由蘋果後台私密金鑰簽名的資料包。