寫在前面

近期都在做自動(dòng)化測(cè)試相關(guān)的工作，已經(jīng)蠻久沒有正正經(jīng)經(jīng)開發(fā)iOS了。其實(shí)自動(dòng)化測(cè)試相關(guān)的還是有蠻多知識(shí)或者內(nèi)容可以拎出來(lái)深入分享下的，看我啥時(shí)候不懶了再說(shuō)吧...

為了測(cè)全公司所有部門的包，需要在測(cè)試前先把他們的包裝在自動(dòng)化測(cè)試機(jī)上。問(wèn)題是不同部門的開發(fā)者賬號(hào)可能不是同一個(gè)，即使是同一個(gè)，不同的包對(duì)應(yīng)的描述文件必定不相同，而我們平臺(tái)最近又在瘋狂加新機(jī)，所以就有了這樣的問(wèn)題：
購(gòu)買新機(jī)后，他們要能在新的機(jī)器上跑，就必須往賬號(hào)的設(shè)備列表里加設(shè)備，然后更新描述文件，然后重新打包，新包才能裝在新機(jī)上。每個(gè)包都得來(lái)一遍這個(gè)過(guò)程，每來(lái)一個(gè)新機(jī)又得重復(fù)一遍。這樣的效率太低，且會(huì)讓開發(fā)煩躁，而解決問(wèn)題最好的辦法就是重簽名。

這篇文章不會(huì)介紹如何重簽名，因?yàn)檫@樣的教程網(wǎng)上已經(jīng)不計(jì)其數(shù)了。本文會(huì)在介紹iOS簽名的基礎(chǔ)上，用比較好懂的話來(lái)解釋加密、數(shù)字簽名、數(shù)字證書原理，再將原理應(yīng)用到實(shí)例中，做更好的理解。

原理

對(duì)稱加密算法

加密解密是使用同一把鑰匙。

比如小明和小紅溝通時(shí)，使用同一把鑰匙A進(jìn)行加解密。
小明將你好啊用鑰匙A加密后生成&^%$，發(fā)送給小紅，小紅用鑰匙A進(jìn)行解密，生成你好啊。

常用的對(duì)稱加密的算法：

1. DES（Data Encryption Standard）：數(shù)據(jù)加密標(biāo)準(zhǔn)，速度較快，適用于加密大量數(shù)據(jù)的場(chǎng)合。
2. 3DES（Triple DES）：是基于DES，對(duì)一塊數(shù)據(jù)用三個(gè)不同的密鑰進(jìn)行三次加密，強(qiáng)度更高。
3. AES（Advanced Encryption Standard）：高級(jí)加密標(biāo)準(zhǔn)，是下一代的加密算法標(biāo)準(zhǔn)，速度快，安全級(jí)別高；

非對(duì)稱加密算法

有一對(duì)鑰匙，稱為公鑰和私鑰。用其中一把鑰匙進(jìn)行加密，就只要另一把鑰匙才能解密，反之也是一樣的。公鑰是公開出去的，私鑰是自己藏著的。

比如小明和小紅溝通時(shí)，小紅生成一對(duì)鑰匙B，公鑰給小明，私鑰自己藏著。
小明將你好啊用公鑰B加密后生成$%^&，在發(fā)送給小紅，小紅用自己的私鑰B解析，生成你好啊。

常用的非對(duì)稱加密的算法：

1. RSA：由 RSA 公司發(fā)明，是一個(gè)支持變長(zhǎng)密鑰的公共密鑰算法，需要加密的文件塊的長(zhǎng)度也是可變的；
2. DSA（Digital Signature Algorithm）：數(shù)字簽名算法，是一種標(biāo)準(zhǔn)的 DSS（數(shù)字簽名標(biāo)準(zhǔn)）；
3. ECC（Elliptic Curves Cryptography）：橢圓曲線密碼編碼學(xué)。

摘要算法

摘要算法在加密過(guò)程中不需要密鑰，且加密后的內(nèi)容無(wú)法解密逆向。它能把任意長(zhǎng)度的數(shù)據(jù)加密成長(zhǎng)度固定的字符串。

比如你好啊用摘要算法加密后，變成!@#$。但是再也做不到通過(guò)!@#$恢復(fù)成你好啊。

著名的摘要算法：

1. MD5算法
2. SHA-1算法

數(shù)字簽名

用摘要算法對(duì)一段數(shù)據(jù)進(jìn)行加密，再使用非對(duì)稱加密的算法中的私鑰對(duì)摘要算法加密后的內(nèi)容二次加密，就能生成數(shù)字簽名。

嗯，聽起來(lái)比較繞。還是舉個(gè)例子。
比如你好啊用摘要算法加密后，變成亂碼1。再用私鑰進(jìn)行加密，生成亂碼2。最后的亂碼2就是簽名。

根據(jù)上面摘要算法的說(shuō)明，摘要算法加密后的內(nèi)容無(wú)法解密逆向。因此簽名亂碼2最多只能通過(guò)公鑰解密成亂碼1，而無(wú)法恢復(fù)你好啊。

那這玩意有啥用呢？其實(shí)這個(gè)簽名是用來(lái)驗(yàn)證原數(shù)據(jù)是否被篡改的。
一般，數(shù)據(jù)發(fā)送方會(huì)把你好啊和這個(gè)簽名亂碼2一起發(fā)出去。接受方在收到后，按照前面寫的順序，先將亂碼2通過(guò)公鑰解密成亂碼1，然后再用摘要算法加密原數(shù)據(jù)你好啊，也生成亂碼1。兩個(gè)比對(duì)后，就能知道數(shù)據(jù)沒有被篡改了。

總之：
數(shù)據(jù) + 摘要算法 = 摘要
摘要 + 私鑰 = 數(shù)字簽名
（數(shù)字簽名就是用來(lái)驗(yàn)證數(shù)據(jù)是否被篡改的）

數(shù)字證書

小明給小紅發(fā)送你好啊和亂碼2，理論上說(shuō)，小紅就能安全無(wú)誤的收到數(shù)據(jù)了。但是光有數(shù)字簽名就安全了嗎？其實(shí)不是的。
有一個(gè)黑客小黑，他先把小紅電腦里的小明的公鑰給改成自己的 ，就能做到神不知鬼不覺的假裝自己是小明了。

小黑發(fā)送你壞啊，用摘要算法加密生成亂碼3，再用自己的私鑰加密生成亂碼4。然后將你壞啊和亂碼4一同發(fā)給小紅。小紅收到后，由于公鑰已經(jīng)被替換，還是能將解密后的亂碼3對(duì)應(yīng)上，從而誤會(huì)小明。

這里，有一個(gè)問(wèn)題就暴露出來(lái)了，如何能證明小紅手里的公鑰是小明生成的呢？數(shù)字證書的作用就顯現(xiàn)出來(lái)了。

簡(jiǎn)單的說(shuō)，數(shù)字證書類似一個(gè)身份證，頒發(fā)數(shù)字證書的是中間人CA機(jī)構(gòu)，類似公安局。那么為啥數(shù)字證書就能證明這個(gè)里面的公鑰是小明的呢？

首先，來(lái)看看數(shù)字證書是咋實(shí)現(xiàn)的。
小明將自己的公鑰發(fā)送給CA，CA會(huì)將公鑰、簽發(fā)者ID、Subject、有效期等數(shù)據(jù)塞進(jìn)一個(gè)文件F里面，內(nèi)容都是明文。然后使用摘要算法進(jìn)行計(jì)算，生成的結(jié)果為H。再用CA的私鑰加密，生成 簽名S。最后將F和S放一起，就是數(shù)字證書Z了。
這里的步驟和上文的簽名步驟類似。

然后再來(lái)看看為啥能證明這證書里的公鑰就是小明的呢？
當(dāng)小明將要發(fā)送的數(shù)據(jù)和這個(gè)數(shù)字證書Z一同發(fā)給小紅，小紅可以從證書里面拿到一個(gè)明文F和簽名S，由于這個(gè)證書是權(quán)威機(jī)構(gòu)發(fā)布的，因此小紅的電腦里存在CA的公鑰，再使用CA公鑰即可將簽名S解碼，拿到H'。再將明文F做摘要算法加密拿到H，只需要比較H和H'是否一致即可。如果一致就確認(rèn)拿到可靠的小明的公鑰了。
這里的步驟又和上文的簽名步驟類似。

總之：
公鑰 + 其他數(shù)據(jù) =  完整數(shù)據(jù)
完整數(shù)據(jù) + 摘要算法 = 簽名
完整數(shù)據(jù) + 簽名 = 數(shù)字證書
（數(shù)字證書就是用來(lái)驗(yàn)證數(shù)據(jù)來(lái)源是否可靠的）

小結(jié)

最后小明和小紅的通信就會(huì)變成這樣：
小明先從CA那邊拿到了認(rèn)證過(guò)的數(shù)字證書Z。再將你好啊通過(guò)摘要算法生成亂碼1，再通過(guò)私鑰加密獲得簽名亂碼2。最后把你好啊 + 亂碼2 + 數(shù)字證書Z 一同發(fā)給小紅。
小紅先通過(guò)數(shù)字證書Z獲得小明公鑰，確認(rèn)公鑰正常后，將簽名亂碼2解碼，可以獲得亂碼1，再用摘要算法將你好啊也加密獲得亂碼1'，比對(duì)即可知道數(shù)據(jù)是否被篡改。
經(jīng)過(guò)這么一個(gè)流程下來(lái)，小紅就能確定你好啊一定是小明發(fā)的。

這時(shí)候小黑還能干壞事嗎？
小黑拿到了小明發(fā)給小紅的數(shù)據(jù)，里面有你好啊 + 亂碼2 + 數(shù)字證書Z。
小黑想先從 數(shù)字證書Z下手，他通過(guò)電腦里的CA公鑰，拿到了小明的公鑰，將自己的公鑰塞進(jìn)去，然后發(fā)現(xiàn)他不能再生成簽名了，因?yàn)樗麤]有CA的私鑰。因此他做不到替換小明公鑰。即使強(qiáng)行生成一個(gè)證書，小紅的瀏覽器也能一眼認(rèn)出這個(gè)證書是不受認(rèn)證的。
那么能不能改下內(nèi)容呢？他用你壞啊通過(guò)摘要算法生成亂碼1，由于沒有小明私鑰，只能用自己的私鑰生成簽名亂碼2。再將你壞啊 + 亂碼2（假的） + 數(shù)字證書Z給小紅。
小紅先通過(guò)數(shù)字證書Z獲得小明公鑰，確認(rèn)公鑰正常后，去解碼簽名亂碼2（假的），生成亂碼1（假的），再用摘要算法將你壞啊生成亂碼1（假的）'，比對(duì)后不一致，同樣失敗。

因此可以確定，小黑無(wú)法再篡改小明的數(shù)據(jù)了。

但是這邊還是有問(wèn)題的，小明的數(shù)據(jù)是明文傳輸?shù)摹＝酉聛?lái)看看HTTPS是如何解決這些問(wèn)題的。

應(yīng)用

HTTPS

建立連接以及通訊過(guò)程：

1. 客戶端向服務(wù)器發(fā)送通信請(qǐng)求
2. 服務(wù)器向客戶端發(fā)送CA授權(quán)的證書
3. 客戶端收到證書后，驗(yàn)證證書有效性。如果有效，會(huì)生成一個(gè)隨機(jī)字符給服務(wù)器，讓服務(wù)器加密
4. 服務(wù)器用私鑰加密完返回客戶端
5. 客戶端解密服務(wù)器返回的數(shù)據(jù)，如果和當(dāng)初發(fā)過(guò)去的一致，說(shuō)明對(duì)方確實(shí)是私鑰持有者。然后客戶端生成對(duì)稱秘鑰，用服務(wù)器公鑰進(jìn)行加密，隨后發(fā)送服務(wù)器。

這段流程結(jié)束后，服務(wù)器和客戶端就能用客戶端定制的秘鑰進(jìn)行數(shù)據(jù)傳輸。

可以看到，第2、3步其實(shí)就是對(duì)數(shù)字證書的應(yīng)用。

iOS簽名

接下來(lái)會(huì)解釋iOS簽名的原理已經(jīng)app安裝時(shí)的原理，如果你對(duì)iOS開發(fā)證書、描述文件申請(qǐng)流程不是很了解的話，建議先去了解后再來(lái)看。

申請(qǐng)iOS開發(fā)者證書的流程

1. 我們?cè)阼€匙串中可以申請(qǐng)到本臺(tái)電腦的證書。其實(shí)證書里包含著我們電腦的公鑰。這一步和小明將自己的公鑰發(fā)給CA是一致的。
2. 在開發(fā)者官網(wǎng)申請(qǐng)開發(fā)者證書時(shí)，我們將電腦的證書上傳上去，蘋果用私鑰進(jìn)行簽名，然后獲得開發(fā)者證書。其實(shí)，開發(fā)者證書和CA給小明的數(shù)字證書是一樣的。
3. 由于iOS開發(fā)真機(jī)調(diào)試過(guò)程中，涉及到測(cè)試的app、環(huán)境權(quán)限和可測(cè)試的設(shè)備，因此蘋果將這些配置包括開發(fā)者證書放一起，用私鑰簽名，然后將原數(shù)據(jù)和簽名放一起作為描述文件。
4. 我們將開發(fā)者證書和描述文件下載下來(lái)，雙擊安裝到描述文件夾中。Xcode編譯前，需要選中正確的開發(fā)者賬號(hào)和描述文件。
5. 打包時(shí)，Xcode會(huì)使用本地私鑰簽名app，同時(shí)會(huì)將描述文件和開發(fā)者證書打包進(jìn)app包中。（這一步的具體流程不是很確定，大致是，先用摘要算法對(duì)app里面的文件進(jìn)行加密，會(huì)生成一個(gè)摘要文件，然后再用私鑰進(jìn)行簽名，簽名后的文件會(huì)放在app的可執(zhí)行文件中（不確定?。。。?/li>
6. 手機(jī)安裝包時(shí)，會(huì)用手機(jī)內(nèi)部的蘋果公鑰解密證書，拿到電腦的公鑰，同時(shí)也會(huì)驗(yàn)證一遍描述文件。這一步和小紅拿到小明的證書很像。
7. 解密得到電腦公鑰后，驗(yàn)證證書和描述文件。如果都符合條件，驗(yàn)證app簽名，而后正常安裝。

最后

以上就是數(shù)字簽名、證書原理及應(yīng)用。如果哪里有問(wèn)題請(qǐng)指出謝謝。
嗨，寫一篇文章可真是太累了，且看且珍惜 _(:з」∠) _

參考：

1. [轉(zhuǎn)載]數(shù)字證書原理，公鑰私鑰加密 - 讀過(guò)最淺顯易懂的密鑰topic
2. 數(shù)字證書的原理是什么？
3. 數(shù)字簽名、數(shù)字證書、對(duì)稱加密算法、非對(duì)稱加密算法、單向加密（散列算法）