常用加密算法
對稱加密算法：AES潭流、DES
加密和解密使用同一密鑰难菌。
- 加密速度快
- 密鑰管理困難途乃，任意泄密
非對稱加密算法：RSA、DSA扔傅、ECC
加密和解密使用不同密鑰，分為私鑰和公鑰烫饼，私鑰加密的數(shù)據(jù)只有公鑰可以解密猎塞，反之亦然。私鑰一般保存在本地杠纵，公鑰用于共享荠耽。
- 加密速度畢竟慢，適用于數(shù)據(jù)量小比藻、安全需求高的數(shù)據(jù)加密
- 不容易泄密
散列算法：MD5铝量、SHA1
又稱哈希算法、摘要算法银亲，是將任意長度的數(shù)據(jù)映射到有限固定長度的域上慢叨，是一種單向不可逆算法。
- 簽名認(rèn)證
- 數(shù)據(jù)的完整性驗(yàn)證
- 不可還原的數(shù)據(jù)存儲务蝠，例如密碼
信息摘要
將任意長度的數(shù)據(jù)通過哈希算法得到固定長度的數(shù)據(jù)拍谐，得到的數(shù)據(jù)就稱為原數(shù)據(jù)的摘要。摘要主要的作用是保證信息完整性馏段。
- 無論數(shù)據(jù)多長轩拨，計算出的摘要長度是固定的
- 摘要看起來是 “隨機(jī)的”，保證無法逆向院喜，無法從摘要中找到任何與原內(nèi)容有關(guān)系
- 相同內(nèi)容的摘要是相同的亡蓉，不同內(nèi)容的摘要是不同的，極端情況下喷舀，不同內(nèi)容的摘要有可能相同砍濒，需要做碰撞處理，越好的算法碰撞的概率越低
數(shù)字簽名
以前日常生活中硫麻，人們通常是用簽名梯影、印章之類來證明信息的可靠。隨著互聯(lián)網(wǎng)的普及庶香，越來越多的信息被數(shù)據(jù)化甲棍，那么怎么在網(wǎng)絡(luò)上確認(rèn)一份信息的可靠性呢？
加密是個不錯的選擇，發(fā)送者對信息進(jìn)行加密感猛，接收者對信息進(jìn)行解密。如果采用對稱加密陪白，就會面臨密鑰管理困難的風(fēng)險，所以非對稱加密是一個不錯的選擇咱士。
發(fā)送者生成一對密鑰，私鑰自己保存序厉，公鑰公開出去。每次發(fā)送信息前弛房，用私鑰對信息進(jìn)行加密道盏，接收者用對應(yīng)公鑰進(jìn)行解密文捶，這樣似乎能保證接到信息是可靠的荷逞。但是當(dāng)信息量很大的時候，非對稱加密會很慢粹排，而且我們只是想證明信息的來源是可靠的种远，不一定要去加密整個內(nèi)容。
這個時候信息摘要顯得特別有用顽耳，我們只需要計算出原信息的摘要院促，用私鑰對摘要進(jìn)行加密，這個時候得到的就是數(shù)字簽名斧抱，然后我們把原信息和數(shù)字簽名一同打包發(fā)送出去常拓，接收者收到信息之前，先用公鑰解密數(shù)字簽名辉浦，得到摘要弄抬，最后用同樣的哈希算法計算信息的摘要，對比之前解密出的摘要宪郊，就可以得出接收到的信息是否可靠和完整了掂恕。
App 簽名
為什么需要 App 簽名
iOS 出來之前，各種操作系統(tǒng)安裝軟件是不需要經(jīng)過任何認(rèn)證的弛槐，所以軟件從哪兒下載都可以安裝運(yùn)行懊亡，導(dǎo)致平臺對第三方軟件難以控制，盜版猖狂乎串，而且會有安全問題店枣。Apple 為了杜絕這種現(xiàn)象，所以采用了 App 簽名驗(yàn)證的方式，來保證每個 App 安裝到 iOS 上都是經(jīng)過允許的鸯两。
App 簽名原理
簡單來說闷旧，就是在 App 打包的時候加入簽名，然后在用戶下載啟動時校對簽名钧唐，成功就正常運(yùn)行忙灼，失敗則閃退。
一般這種驗(yàn)證都會采用非對稱加密算法钝侠，Apple 也不例外该园，Apple 會生成一對密鑰：私鑰保存在服務(wù)器，公鑰下發(fā)到 iOS 設(shè)備帅韧。這樣開發(fā)者將開發(fā)好的 App 上傳到 Apple 服務(wù)器的時候里初，Apple 服務(wù)器會用私鑰加密該 App 的摘要從而生成數(shù)字簽名，用戶從 App Store 下載 App 的時候弱匪，就會用本地的公鑰來校驗(yàn)。
簡單流程如下：
這樣看起很簡單的樣子璧亮，但是這并不能滿足所有的場景萧诫，試想一下，我們會在哪些場景下有安裝 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 服務(wù)器的衅枫，不能都先去 Apple 認(rèn)證一下吧。既然我們知道校驗(yàn)的方式通常是通過一對密鑰來驗(yàn)證的步咪，那我們是否可以在本地生成一對密鑰益楼，然后重復(fù)上面的步驟呢？這樣就可以不用把 App 上傳到 Apple 服務(wù)器了悯周，但是有兩個問題：
- 用戶如何拿到我們本地生成的公鑰禽翼？
- 蘋果失去了安裝認(rèn)可的權(quán)利族跛？
為了避免上述兩個問題，Apple 采用了雙重簽名的機(jī)制长酗。
簡單來說：就是由 Apple 生成的一對密鑰來驗(yàn)證 App桐绒，轉(zhuǎn)變?yōu)?Apple 的一對密鑰來驗(yàn)證我們本地生成的一對密鑰，然后拿我們生成的一對密鑰來驗(yàn)證 App咧叭。
流程上來說佳簸，我們會先把本地生成的 公鑰 L 上傳到 Apple 服務(wù)器颖变，Apple 服務(wù)器會使用自己的 私鑰 A 對 公鑰 L 進(jìn)行加密簽名生成證書提供給我們下載，然后我們用本地的 私鑰 L 對 App 進(jìn)行簽名連同下載的證書一起打包成 ipa 文件马胧，提供給用戶下載衔峰。用戶下載的時候蛙粘，會先用內(nèi)置的 Apple 公鑰 A 去對 ipa 文件里面的證書進(jìn)行校驗(yàn)威彰，校驗(yàn)成功之后，取出證書里面的 公鑰 L 舔痕，然后用 公鑰 L 去校驗(yàn) app 的簽名豹缀，通過后即可安裝運(yùn)行邢笙。
我們可以清楚地看出：私鑰保存本地用于簽名，公鑰分發(fā)出去用于校驗(yàn)叮雳。
上面我們簡單描述了雙重簽名的機(jī)制妇汗，雖然已經(jīng)有點(diǎn)復(fù)雜了，但是 Apple 對于 App 的權(quán)限控制不限于此厌均，Apple 還希望控制：
設(shè)備列表（允許安裝的設(shè)備）
App ID（App 唯一標(biāo)識）
App 的各種權(quán)限（推送告唆、iCloud擒悬、后臺運(yùn)行等權(quán)限）
這些信息都會同上面我們下載的證書一起打包成 Provisioning Profile，所以流程上就顯得更加復(fù)雜懂牧， 具體流程如下：
Https
Https 就是在 http 的基礎(chǔ)上添加了一層 SSL / TLS 協(xié)議僧凤，來保證數(shù)據(jù)傳輸?shù)陌踩浴?而傳輸?shù)陌踩泽w現(xiàn)在下面幾個方面：
- 身份認(rèn)證
- 內(nèi)容加密
- 數(shù)據(jù)完整
這些安全的保證本質(zhì)上也是通過加密算法來實(shí)現(xiàn)的躯保，核心來講：
通過非對稱加密來共享對稱加密的密鑰澎语，然后通過對稱加密來進(jìn)行通信验懊。
整體流程：
有關(guān)證書 & 密鑰流程：
