蘋果證書和公鑰私鑰加密
今天看了點關於公私鑰加密的內容，趕快記下省的忘記了。
這裏有幾個概念：公鑰，私鑰，加密，認證，認證中心(CA)，數字證書。
公鑰和私鑰是屬於非對稱性加密，公鑰和私鑰是完全不同的，但是相互對應的。一把私鑰只能對應一把公鑰。顧名思義，公鑰是對外開放的，所有人都可以獲得，私鑰是自己保管的。
加密與認證
基於公鑰的加密
加密的目的是保證密文只能由特定人讀取，其他人都不能獲知裏面的內容。公鑰的作用就是加密。舉例說明：Alices發信息給Bob。她會用Bob給的公鑰對明文進行加密。Bob得到密文後，用自己的私鑰解密。這個過程保證即使其他人得到了密文也沒法看。
圖1
基於私鑰的認證
私鑰的作用是鑒別用戶的真偽。還是上面的例子，Alices給Bob發信。但是Bob的公鑰很多人都有，如何知道收到的信是Alices發的呢？就要靠私鑰認證。Alices給Bob發信的時候可以附帶一段信息，然後通過自己的私鑰把這段信息加密。Bob收到信後，首先用Alices的公鑰就附帶信息進行解密，如果正確就說明這封信確實是Alices發的，然後再用自己的私鑰解密信的具體內容。
圖2
認證中心(CA)與數字證書
認證中心的作用是保證公鑰的正確。比如：Alices想給Bob發一封絕密的信件，而此時，Alices和Bob都沒有對方的公鑰。這時，Bob給Alices的公鑰，Alices如果知道是Bob給的而不是其他人冒充給的？怎麽辦？！這時就要CA出馬了。Bob提交自己信息和公鑰給CA。CA通過自己的私鑰加密這些信息，生成一個數字證書。Bob把這個數字證書給Alices，Alices通過CA的公鑰對數字證書解密，得到公鑰就是Bob的公鑰。
個人感覺非對稱加密一個很重要的一環就是CA的作用。首先，CA要保證它的公鑰不能被替換，否則都別玩了。這個估計不難，確定個網址，只有從這下載的才是CA的公鑰。或是其他更高級的措施。其次，CA要保證對個人的認證。比如Tom提交個人信息和公鑰後CA就要保證不能冒充為Bob的。這個估計靠人或其他措施，總之能保證。這些都是CA的事，我們不管。
圖3
蘋果的簽名
重頭戲來了，下面就說一下蘋果的簽名與上面的關系。搞了這麽久的iOS開發，經常被開發中各種證書給搞暈，這真是一個大坑，但是不得不過。
一、數字簽名（digital signature）
對指定信息使用哈希算法，得到一個固定長度的信息摘要，然後再使用 私鑰 （註意必須是私鑰）對該摘要加密，就得到了數字簽名。所謂的代碼簽名就是這個意思。
二、數字證書（digital certificate）
證書生成
開發者在申請iOS開發證書時，需要通過keychain生成一個CSR文件（Certificate Signing Request），提交給蘋果的 Apple Worldwide Developer Relations Certification Authority(WWDR)證書認證中心進行簽名，最後從蘋果官網下載並安裝使用。這個過程中還會產生一個私鑰，證書和私鑰在keychain中得位置如圖：
圖4
證書組成
經過WWDR數字簽名後的數字證書長這個樣子：
其中包含兩大部分：
· 證書本身
包含用戶的公鑰、用戶個人信息、證書頒發機構信息、證書有效期等信息。
· 證書簽名
WWDR將上述證書本身內容的使用哈希算法得到一個固定長度的信息摘要，然後使用自己的私鑰對該信息摘要加密生成數字簽名，整個過程如圖所示：
證書使用
iOS系統原本就持有WWDR的公鑰（這裏就保證了CA公鑰的正確性），系統首先會對證書內容通過指定的哈希算法計算得到一個信息摘要；然後使用WWDR的公鑰對證書中包含的數字簽名解密，從而得到經過WWDR的私鑰加密過的信息摘要；最後對比兩個信息摘要，如果內容相同就說明該證書可信。整個過程如圖所示：
在驗證了證書是可信的以後，iOS系統就可以獲取到證書中包含的開發者的公鑰，並使用該公鑰來判斷代碼簽名的可用性了。
證書存在的意義
通過證書使用過程可以看出，證書本身只是一個中間媒介，iOS系統對證書並不關心，它其實只想要證書中包含的開發者的公鑰！！
但是開發者怎麽才能證明公鑰是自己的呢？iOS安全系統怎麽才能相信這個公鑰就是這個開發者的呢？
不管是哪一個開發者對iOS的安全系統說，這個公鑰就是我的，系統是都不相信的，即系統對開發者有著百分之百的不信任感。但是iOS安全系統對自家的WWDR是可信任的，蘋果將WWDR的公鑰內置在了iOS系統中。有了證書，iOS安全系統只需要通過WWDR的公鑰就可以獲取到任何一個開發者的可信任的公鑰了，這就是證書存在的意義！！
三、公鑰（public key）
公鑰被包含在數字證書裏，數字證書又被包含在描述文件(Provisioning File)中，描述文件在應用被安裝的時候會被拷貝到iOS設備中。
iOS安全系統通過證書就能夠確定開發者身份，就能夠通過從證書中獲取到的公鑰來驗證開發者用該公鑰對應的私鑰簽名後的代碼、資源文件等有沒有被更改破壞，最終確定應用能否合法的在iOS設備上合法運行。
四、私鑰（private key）
每個證書（其實是公鑰）都對應有一個私鑰，
私鑰會被用來對代碼、資源文件等簽名。只有開發證書和描述文件是沒辦法正常調試的，因為沒有私鑰根本無法簽名。
五、provisioning profile的生成
還記得剛開始為了生成這玩意也費了很大勁。首先通過鑰匙串生成一個csr文件，把這個文件提交給蘋果開發中心，生成一個cer文件。其實這個過程就是把自己的公鑰給Apple，至於上面提到的如果保證公鑰的確定性，就靠進入開發中心的賬號和密碼了，如果這玩意泄露了，那就誰也無能為力。
下載安裝cer文件後，就會在鑰匙串中多出個選項，如圖4所示。下面是自己的私鑰，這個很重要。別問私鑰存在哪，我也不知道，但是它能導出為p12文件。
cer搞定後就是在開發者中心添加appID，設備等，不詳述了。 最後到生成provisioning profile。首先你要選類型，就是用於開發還是用於發布，其次是appID。下面的選項很重要，是選擇certificates，這個就是選擇你要包含的公鑰，它是用來加密用的，我一般會都選。如果是開發的話，下面就是選擇設備了，然後命個名就完事了。設計到加密的就是certificates的選擇。
所以開發的時候私鑰也就是P12文件和provisioning profile匹配是最重要的。私鑰對代碼進行加密，公鑰解密。整個過程就是認證的過程，保證了，iOS設備安裝的程序是經過蘋果審核同意的。這也就是蘋果費這麽大勁的目的。
在Xcode6中codesing和provisioning配置都是可選擇的，選擇一定的匹配，否則要不是真機調不了，要不就是上傳不成功。
簡述一下整個過程：首先開發者上傳csr文件，即把公鑰給蘋果。生成provisioning profile時選擇對應的公鑰。然後下載安裝相應的provisioning文件。在程序打包時，會用私鑰就代碼進行加密，然後把provisioning文件包含到app文件中。當iOS設備安裝應用時，首先用CA的公鑰解密出開發者的公鑰，然後再用開發者的公鑰解密出代碼，完成安裝。
看來蘋果為了保證代碼的來源，也是蠻拼的！
http://blog.csdn.net/electronmc/article/details/45014591
蘋果證書和公鑰私鑰加密