今天看了點關於公私鑰加密的內容,趕快記下省的忘記了。html
這裏有幾個概念:公鑰,私鑰,加密,認證,認證中心(CA),數字證書。git
公鑰和私鑰是屬於非對稱性加密,公鑰和私鑰是徹底不一樣的,可是相互對應的。一把私鑰只能對應一把公鑰。顧名思義,公鑰是對外開放的,全部人均可以得到,私鑰是本身保管的。算法
加密與認證segmentfault
基於公鑰的加密
安全
加密的目的是保證密文只能由特定人讀取,其餘人都不能獲知裏面的內容。公鑰的做用就是加密。舉例說明:Alices發信息給Bob。她會用Bob給的公鑰對明文進行加密。Bob獲得密文後,用本身的私鑰解密。這個過程保證即便其餘人獲得了密文也無法看。app
圖1iphone
基於私鑰的認證electron
私鑰的做用是鑑別用戶的真僞。仍是上面的例子,Alices給Bob發信。可是Bob的公鑰不少人都有,如何知道收到的信是Alices發的呢?就要靠私鑰認證。Alices給Bob發信的時候能夠附帶一段信息,而後經過本身的私鑰把這段信息加密。Bob收到信後,首先用Alices的公鑰就附帶信息進行解密,若是正確就說明這封信確實是Alices發的,而後再用本身的私鑰解密信的具體內容。ide
圖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開發,常常被開發中各類證書給搞暈,這真是一個大坑,可是不得不過。
1、數字簽名(digital signature)
對指定信息使用哈希算法,獲得一個固定長度的信息摘要,而後再使用 私鑰 (注意必須是私鑰)對該摘要加密,就獲得了數字簽名。所謂的代碼簽名就是這個意思。
2、數字證書(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的公鑰就能夠獲取到任何一個開發者的可信任的公鑰了,這就是證書存在的意義!!
3、公鑰(public key)
公鑰被包含在數字證書裏,數字證書又被包含在描述文件(Provisioning File)中,描述文件在應用被安裝的時候會被拷貝到iOS設備中。
iOS安全系統經過證書就可以肯定開發者身份,就可以經過從證書中獲取到的公鑰來驗證開發者用該公鑰對應的私鑰簽名後的代碼、資源文件等有沒有被更改破壞,最終肯定應用可否合法的在iOS設備上合法運行。
4、私鑰(private key)
每一個證書(實際上是公鑰)都對應有一個私鑰,
私鑰會被用來對代碼、資源文件等簽名。只有開發證書和描述文件是沒辦法正常調試的,由於沒有私鑰根本沒法簽名。
5、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
其餘:http://blog.csdn.net/lvxiangan/article/details/17306269
https://segmentfault.com/a/1190000006128813
http://www.cnblogs.com/ioriwellings/p/5066652.html