常用加密算法
對稱加密算法：AES、DES
加密和解密使用同一密鑰。
- 加密速度快
- 密鑰管理困難，任意泄密
非對稱加密算法：RSA、DSA、ECC
加密和解密使用不同密鑰，分為私鑰和公鑰，私鑰加密的數(shù)據(jù)只有公鑰可以解密，反之亦然。私鑰一般保存在本地，公鑰用于共享。
- 加密速度畢竟慢，適用于數(shù)據(jù)量小、安全需求高的數(shù)據(jù)加密
- 不容易泄密
散列算法：MD5、SHA1
又稱哈希算法、摘要算法，是將任意長度的數(shù)據(jù)映射到有限固定長度的域上，是一種單向不可逆算法。
- 簽名認證
- 數(shù)據(jù)的完整性驗證
- 不可還原的數(shù)據(jù)存儲，例如密碼
信息摘要
將任意長度的數(shù)據(jù)通過哈希算法得到固定長度的數(shù)據(jù)，得到的數(shù)據(jù)就稱為原數(shù)據(jù)的摘要。摘要主要的作用是保證信息完整性。
- 無論數(shù)據(jù)多長，計算出的摘要長度是固定的
- 摘要看起來是 “隨機的”，保證無法逆向，無法從摘要中找到任何與原內(nèi)容有關(guān)系
- 相同內(nèi)容的摘要是相同的，不同內(nèi)容的摘要是不同的，極端情況下，不同內(nèi)容的摘要有可能相同，需要做碰撞處理，越好的算法碰撞的概率越低
數(shù)字簽名
以前日常生活中，人們通常是用簽名、印章之類來證明信息的可靠。隨著互聯(lián)網(wǎng)的普及，越來越多的信息被數(shù)據(jù)化，那么怎么在網(wǎng)絡上確認一份信息的可靠性呢？
加密是個不錯的選擇，發(fā)送者對信息進行加密，接收者對信息進行解密。如果采用對稱加密，就會面臨密鑰管理困難的風險，所以非對稱加密是一個不錯的選擇。
發(fā)送者生成一對密鑰，私鑰自己保存，公鑰公開出去。每次發(fā)送信息前，用私鑰對信息進行加密，接收者用對應公鑰進行解密，這樣似乎能保證接到信息是可靠的。但是當信息量很大的時候，非對稱加密會很慢，而且我們只是想證明信息的來源是可靠的，不一定要去加密整個內(nèi)容。
這個時候信息摘要顯得特別有用，我們只需要計算出原信息的摘要，用私鑰對摘要進行加密，這個時候得到的就是數(shù)字簽名，然后我們把原信息和數(shù)字簽名一同打包發(fā)送出去，接收者收到信息之前，先用公鑰解密數(shù)字簽名，得到摘要，最后用同樣的哈希算法計算信息的摘要，對比之前解密出的摘要，就可以得出接收到的信息是否可靠和完整了。
App 簽名
為什么需要 App 簽名
iOS 出來之前，各種操作系統(tǒng)安裝軟件是不需要經(jīng)過任何認證的，所以軟件從哪兒下載都可以安裝運行，導致平臺對第三方軟件難以控制，盜版猖狂，而且會有安全問題。Apple 為了杜絕這種現(xiàn)象，所以采用了 App 簽名驗證的方式，來保證每個 App 安裝到 iOS 上都是經(jīng)過允許的。
App 簽名原理
簡單來說，就是在 App 打包的時候加入簽名，然后在用戶下載啟動時校對簽名，成功就正常運行，失敗則閃退。
一般這種驗證都會采用非對稱加密算法，Apple 也不例外，Apple 會生成一對密鑰：私鑰保存在服務器，公鑰下發(fā)到 iOS 設(shè)備。這樣開發(fā)者將開發(fā)好的 App 上傳到 Apple 服務器的時候，Apple 服務器會用私鑰加密該 App 的摘要從而生成數(shù)字簽名，用戶從 App Store 下載 App 的時候，就會用本地的公鑰來校驗。
簡單流程如下：
這樣看起很簡單的樣子，但是這并不能滿足所有的場景，試想一下，我們會在哪些場景下有安裝 App 的需求？
- 開發(fā) App 時，通過 Xcode 安裝到 iPhone
- 發(fā)布 App 時，通過上傳到 App Store，用戶下載安裝
- 通過 ad-hoc 的形式分發(fā) App，有數(shù)量限制，一般用于平常測試
- 通過 in-house 的形式分發(fā) App，無數(shù)量限制，一般用于企業(yè)內(nèi)部大范圍測試
除了通過 Apple Store 之外，對于其他幾種來說，App 的發(fā)布安裝是可能不經(jīng)過 Apple 服務器的，不能都先去 Apple 認證一下吧。既然我們知道校驗的方式通常是通過一對密鑰來驗證的，那我們是否可以在本地生成一對密鑰，然后重復上面的步驟呢？這樣就可以不用把 App 上傳到 Apple 服務器了，但是有兩個問題：
- 用戶如何拿到我們本地生成的公鑰？
- 蘋果失去了安裝認可的權(quán)利？
為了避免上述兩個問題，Apple 采用了雙重簽名的機制。
簡單來說：就是由 Apple 生成的一對密鑰來驗證 App，轉(zhuǎn)變?yōu)?Apple 的一對密鑰來驗證我們本地生成的一對密鑰，然后拿我們生成的一對密鑰來驗證 App。
流程上來說，我們會先把本地生成的 公鑰 L 上傳到 Apple 服務器，Apple 服務器會使用自己的 私鑰 A 對 公鑰 L 進行加密簽名生成證書提供給我們下載，然后我們用本地的 私鑰 L 對 App 進行簽名連同下載的證書一起打包成 ipa 文件，提供給用戶下載。用戶下載的時候，會先用內(nèi)置的 Apple 公鑰 A 去對 ipa 文件里面的證書進行校驗，校驗成功之后，取出證書里面的 公鑰 L ，然后用 公鑰 L 去校驗 app 的簽名，通過后即可安裝運行。
我們可以清楚地看出：私鑰保存本地用于簽名，公鑰分發(fā)出去用于校驗。
上面我們簡單描述了雙重簽名的機制，雖然已經(jīng)有點復雜了，但是 Apple 對于 App 的權(quán)限控制不限于此，Apple 還希望控制：
設(shè)備列表（允許安裝的設(shè)備）
App ID（App 唯一標識）
App 的各種權(quán)限（推送、iCloud、后臺運行等權(quán)限）
這些信息都會同上面我們下載的證書一起打包成 Provisioning Profile，所以流程上就顯得更加復雜， 具體流程如下：
Https
Https 就是在 http 的基礎(chǔ)上添加了一層 SSL / TLS 協(xié)議，來保證數(shù)據(jù)傳輸?shù)陌踩浴?而傳輸?shù)陌踩泽w現(xiàn)在下面幾個方面：
- 身份認證
- 內(nèi)容加密
- 數(shù)據(jù)完整
這些安全的保證本質(zhì)上也是通過加密算法來實現(xiàn)的，核心來講：
通過非對稱加密來共享對稱加密的密鑰，然后通過對稱加密來進行通信。
整體流程：
有關(guān)證書 & 密鑰流程：
