JB的測試之旅-IOS證書及簽名

前言

最近在負責ios的項目，被各類證書跟簽名概念弄的一臉懵逼，並且以前也沒怎麼接觸過IOS的測試，顯的更加小白了，所以想把這塊知識彌補下；

簽名

目的

先來看看蘋果的簽名機制是爲了作什麼。
在 iOS 出來以前，在主流操做系統(Mac/Windows/Linux)上開發和運行軟件是不須要簽名的，軟件隨便從哪裏下載都能運行，致使平臺對第三方軟件難以控制，盜版流行。
蘋果但願解決這樣的問題，在 iOS 平臺對第三方 APP 有絕對的控制權，必定要保證每個安裝到 iOS 上的 APP 都是通過蘋果官方容許的，怎樣保證呢？就是經過簽名機制。

對稱加密

通常說的簽名指的就是數字簽名，它是基於非對稱加密算法實現的；
什麼是非對稱加密？
非對稱加密是相對於對稱加密而言的；
但不管是哪一種方式的加密，目的都是爲了保護被加密的內容；

度娘關於對稱加密的解釋：

採用單鑰密碼系統的加密方法，同一個密鑰能夠同時用做信息的加密和解密，
這種加密方法稱爲對稱加密，也稱爲單密鑰加密。
複製代碼

嗯，看不懂吧？懵逼吧？不要緊，接着看~

jb有一封信,只想給本身跟YY看，因而JB爲這封信設置了密碼（加密），而後寄給YY，YY只要知道信的密碼就能夠查看其中的內容（解密），別人即便拿到信想看，但沒有密碼（密鑰），也沒法查看裏面的內容；

所謂的對稱就是加密和解密的過程使用的是相同的密鑰；

非對稱加密

與對稱加密不一樣,非對稱加密算法的加密和解密使用不一樣的兩個密鑰.這兩個密鑰就是咱們常常聽到的公開密鑰(公鑰)和私有密鑰(私鑰);

公鑰和私鑰的關係是:
公鑰和私鑰通常成對出現；

若是你的消息使用公鑰加密,那麼須要該公鑰對應的私鑰才能解密;

若是你的消息使用私鑰加密,那麼須要該私鑰對應的公鑰才能解密；

非對稱加密的做用是:
保護消息內容, 而且讓消息接收方肯定發送方的身份；

不懂？接着看吧~

仍是上面的例子，使用對稱加密的問題在於，一旦密鑰在傳輸過程當中泄露了，保密性就蕩然無存了；

既然對稱加密的安全性會低一些，那就採用非對稱加密，這樣，JB 跟 YY就須要各自持有一對屬於本身的公鑰和密鑰；

JB寫的信只想給YY看，那麼YY跟別人會有什麼不同的特質呢？那就是YY擁有隻有他本身知道的密鑰！
若是JB使用YY的公鑰加密，那麼就只有YY的密鑰才能解密，這樣就能達到只讓YY看的目的；

這裏須要說明下，公鑰是公開給別人開的哦；

那有一種狀況，既然YY的公鑰是公開的，假若有一個SB想冒充JB，使用YY的公鑰加密而後給YY寫一封信；

JB爲了不這種狀況的發生，把信的內容用JB本身的密鑰進行加密，YY收到信後，使用JB的公鑰解密（只有JB的公鑰才能解開使用JB私鑰加密的內容），若是能夠解開，那麼YY就知道這封信的確是JB發的，這是爲了肯定消息發送方的份；

可能文字看上去會懵逼，所以就花了個流程圖，便於理解：

上面這個，就是非對稱加密，回到IOS自己，當咱們想把寫好的IOS程序運行到真機時，會使用到這種非對稱加密的方式進行認證，從而確保程序的來源是可信且安全的~

數字簽名&證書

那數字簽名又是什麼？
簡單的話，數字簽名的做用是對某一份數據打了標記，表示認這份數據，至關於簽了個名，而後再發送給其餘人，其餘人能夠知道這份數據是通過我認證的，數據沒有被篡改過；

這裏的話，直接貼一峯大神的翻譯文章，方便了解；
連接以下：數字簽名是什麼

1)鮑勃有兩把鑰匙，一把是公鑰，另外一把是私鑰。

2)鮑勃把公鑰送給他的朋友們----帕蒂、道格、蘇珊----每人一把。

3)蘇珊要給鮑勃寫一封保密的信。她寫完後用鮑勃的公鑰加密，就能夠達到保密的效果。

4)鮑勃收信後，用私鑰解密，就看到了信件內容。這裏要強調的是，只要鮑勃的私鑰不泄露，這封信就是安全的，即便落在別人手裏，也沒法解密。

5)鮑勃給蘇珊回信，決定採用"數字簽名"。他寫完後先用Hash函數，生成信件的摘要（digest）。

6)而後，鮑勃使用私鑰，對這個摘要加密，生成"數字簽名"（signature）。

7)鮑勃將這個簽名，附在信件下面，一塊兒發給蘇珊。

8)蘇珊收信後，取下數字簽名，用鮑勃的公鑰解密，獲得信件的摘要。由此證實，這封信確實是鮑勃發出的。

9)蘇珊再對信件自己使用Hash函數，將獲得的結果，與上一步獲得的摘要進行對比。若是二者一致，就證實這封信未被修改過。

10)複雜的狀況出現了。道格想欺騙蘇珊，他偷偷使用了蘇珊的電腦，用本身的公鑰換走了鮑勃的公鑰。此時，蘇珊實際擁有的是道格的公鑰，可是還覺得這是鮑勃的公鑰。所以，道格就能夠冒充鮑勃，用本身的私鑰作成"數字簽名"，寫信給蘇珊，讓蘇珊用假的鮑勃公鑰進行解密。

11)後來，蘇珊感受不對勁，發現本身沒法肯定公鑰是否真的屬於鮑勃。她想到了一個辦法，要求鮑勃去找"證書中心"（certificate authority，簡稱CA），爲公鑰作認證。證書中心用本身的私鑰，對鮑勃的公鑰和一些相關信息一塊兒加密，生成"數字證書"（Digital Certificate）。

12)鮑勃拿到數字證書之後，就能夠放心了。之後再給蘇珊寫信，只要在簽名的同時，再附上數字證書就好了。

13)蘇珊收信後，用CA的公鑰解開數字證書，就能夠拿到鮑勃真實的公鑰了，而後就能證實"數字簽名"是否真的是鮑勃籤的。

正文看完下來，對數字簽名以及數字證書有了初步認識了= =

證書信息

科普

1）蘋果開發者中心網站
2)開發者賬號的類型：
我的-$99（約688元/年）（調試證書最多隻能有兩個）
公司-$99（約688元/年）須要提供鄧白氏編碼，用於企業認證，能夠進行團隊開發管理
企業-$299，須要提供鄧白氏編碼，程序不能上架到AppStore（用於企業內部辦公軟件等）（調試證書最多有五個）

建立證書

1）添加證書

2）選擇證書

• 開發證書（Development）：最多1個（20170425日只能生成一個了）
• 發佈證書（Production）：最多3個

  

3）準備建立CSR文件

4）建立CSR文件01（打開鑰匙串->證書助理->從證書頒發機構請求證書）

5）建立CSR文件02（填寫電子郵件地址，經常使用名稱，這兩項均可以隨便填，注意要把CSR文件存儲到磁盤）

6）建立CSR文件

7）選擇剛剛建立的CSR文件

8）建立證書完畢，下載證書

iOS 的簽名證書機制

AppStore

從 AppStore 下載的應用驗證流程很是簡單，蘋果官方身材一對公私鑰，在ios裏內置一個公鑰，私鑰由蘋果後臺保存，當傳 App 上 AppStore 時，蘋果後臺用私鑰對 APP 數據進行簽名，iOS 系統下載這個 APP 後，用公鑰驗證這個簽名，若簽名正確，這個 APP 確定是由蘋果後臺認證的，而且沒有被修改過，也就達到了蘋果的需求：保證安裝的每個 APP 都是通過蘋果官方容許的。

Xcode Build

那平常開發中，總沒可能每次都提交到App Store的，因此在本地調試時，設備會把對APP的驗證，改爲對開發者的驗證；

此處的開發者帳號，就是在 Apple Developer Center 中所申請的開發者帳號，一旦信任以後，每次 build 的時候，iOS 設備就將驗證該開發者身份，而不是驗證你 build 的 App。如此一來，便省去了應用包上傳、下載的過程。咱們知道，驗證 App 是經過簽名機制，來肯定安裝包來源的，而此處的驗證開發者身份，又是怎樣的機制呢？

驗證開發者

首先，iOS 設備須要驗證你的開發者身份，這是基於 macOS 的一種證書策略，若是打開鑰匙串訪問，選中證書，咱們能夠看到這樣的一堆東西：

在這裏能看到各類各樣的證書；
當在 Xcode 添加本身的帳號後，並在項目中將 Team 選擇爲本身的開發者帳號後，鑰匙串中就多出了這麼一個東西：

證書中存儲着一個「專用密鑰」，這個專用密鑰，是用來給 App 安裝包進行簽名的。
這份密鑰在生成的時候，Xcode 將密鑰的公鑰部分上傳至 Apple 服務器，由 Apple 進行簽名生成證書，最後返回到本地，而私鑰，則會在 Xcode 本地構建安裝時，用來爲 App 安裝包簽名。最後，Xcode 會將簽名後的安裝包和本地證書打包都放到 iOS 設備中，iOS 設備接着使用 Apple 公鑰來解密證書，拿到本地公鑰，接着用本地公鑰去解密 App 。

其實，也就2個事情：

• iOS 設備用 Apple 公鑰解密證書，所拿到的本地證書，一定是通過 Apple 服務器簽名的，也就是說，這裏保證了開發者是通過蘋果認證的。
• 上一步拿到的公鑰，用於解密 App 簽名，若解密成功且驗證經過，證實該 App 確實是由該開發者構建的，也就保證了 App 的安全性。

上述的流程惟一問題是，這個密鑰是在本地生成的，若是更換了電腦，本地的密鑰對就會改變。這時候，你須要將舊 mac 上的證書導出，並安裝到新的電腦上。

小結

本文主要介紹了簽名跟證書的只是，包括對稱加密跟非對稱加密，以及數字證書相關信息，而且介紹了App Store跟xcode的證書邏輯，從大體上對IOS證書這塊起到掃盲的做用，具體細節就再也不深刻了，大體就先這樣吧，後續須要再另寫一篇~

謝謝你們~