一、預(yù)備知識(shí)
1、常見英文
encrypt：加密
decrypt：解密
plaintext：明文
ciphertext：密文
2、為了便于學(xué)習(xí)，設(shè)計(jì)4個(gè)虛擬人物
Alice、Bob：互相通信
Eve：竊聽者
Mallory：主動(dòng)攻擊者
如何防止被竊聽？
如何加密解密？
二、密碼的類型
根據(jù)密鑰的使用方法，可以將密碼分為2種
- 對(duì)稱密碼
- 公鑰密碼（非對(duì)稱密碼）
三、對(duì)稱密碼（Symmetric Cryptography）
在對(duì)稱密碼中，加密、解密時(shí)使用的是同一個(gè)密鑰
常見的對(duì)稱密碼算法有
- DES
- 3DES
- AES
1、DES（Data Encryption Standard）
DES是一種將64bit明文加密成64bit密文的對(duì)稱密碼算法，密鑰長度是56bit
規(guī)格上來說，密鑰長度是64bit，但每隔7bit會(huì)設(shè)置一個(gè)用于錯(cuò)誤檢查的bit，因此密鑰長度實(shí)質(zhì)上是56bit
由于DES每次只能加密64bit的數(shù)據(jù)，遇到比較大的數(shù)據(jù)，需要對(duì)DES加密進(jìn)行迭代（反復(fù)）
目前已經(jīng)可以在短時(shí)間內(nèi)被破解，所以不建議使用
2、3DES
3DES，將DES重復(fù)3次所得到的一種密碼算法，也叫做3重DES
目前還被一些銀行等機(jī)構(gòu)使用，但處理速度不高，安全性逐漸暴露出問題
3個(gè)密鑰都是不同的，也稱為DES-EDE3
如果所有密鑰都使用同一個(gè)，則結(jié)果與普通的DES是等價(jià)的
如果密鑰1、密鑰3相同，密鑰2不同，稱為DES-EDE2
3、AES（Advanced Encryption Standard）
取代DES成為新標(biāo)準(zhǔn)的一種對(duì)稱密碼算法
AES的密鑰長度有128、192、256bit三種
在2000年時(shí)選擇Rijindael算法作為AES的實(shí)現(xiàn)
目前AES，已經(jīng)逐步取代DES、3DES，成為首選的對(duì)稱密碼算法
一般來說，我們也不應(yīng)該去使用任何自制的密碼算法，而是應(yīng)該使用AES，它經(jīng)過了全世界密碼學(xué)家所進(jìn)行的高品質(zhì)驗(yàn)證工作
4、密鑰配送問題
在使用對(duì)稱密碼時(shí)，一定會(huì)遇到密鑰配送問題
假設(shè)，Alice將使用對(duì)稱密碼加密過的消息發(fā)給了Bob
只有將密鑰發(fā)送給Bob，Bob才能完成解密
在發(fā)送密鑰過程中，可能會(huì)被Eve竊取密鑰，最后Eve也能完成解密
如何解決密鑰配送問題
有以下幾種解決密鑰配送的方法
- 事先共享密鑰
- 密鑰分配中心
- Diffie-Hellman密鑰交換
- 公鑰密碼
四、公鑰密碼（Public-key Cryptography）
公鑰密碼中，密鑰分為加密密鑰、解密密鑰2種，它們并不是同一個(gè)密鑰
公鑰密碼也被稱為非對(duì)稱密碼（Asymmetric Cryptography）
在公鑰密碼中
加密密鑰，一般是公開的，因此該密鑰稱為公鑰（public key）
解密密鑰，由消息接收者自己保管的，不能公開，因此也稱為私鑰（private key）
公鑰和私鑰是一 一對(duì)應(yīng)的，是不能單獨(dú)生成的，一對(duì)公鑰和密鑰統(tǒng)稱為密鑰對(duì)（key pair）
由公鑰加密的密文，必須使用與該公鑰對(duì)應(yīng)的私鑰才能解密
由私鑰加密的密文，必須使用與該私鑰對(duì)應(yīng)的公鑰才能解密
解決密鑰配送問題
由消息的接收者，生成一對(duì)公鑰、私鑰
將公鑰發(fā)給消息的發(fā)送者
消息的發(fā)送者使用公鑰加密消息
RSA
目前使用最廣泛的公鑰密碼算法是RSA
RSA的名字，由它的3位開發(fā)者，即Ron Rivest、Adi Shamir、Leonard Adleman的姓氏首字母組成
五、混合密碼系統(tǒng)（Hybrid Cryptosystem）
1、對(duì)稱密碼的缺點(diǎn)
不能很好地解決密鑰配送問題
2、公鑰密碼的缺點(diǎn)
加密解密速度比較慢
3、混合密碼系統(tǒng)，是將對(duì)稱密碼和公鑰密碼的優(yōu)勢相結(jié)合的方法
解決了公鑰密碼速度慢的問題
并通過公鑰密碼解決了對(duì)稱密碼的密鑰配送問題
網(wǎng)絡(luò)上的密碼通信所用的SSL/TLS都運(yùn)用了混合密碼系統(tǒng)
4、混合密碼-加密
會(huì)話密鑰（session key）
為本次通信隨機(jī)生成的臨時(shí)密鑰
作為對(duì)稱密碼的密鑰，用于加密消息，提高速度
加密步驟（發(fā)送消息）
首先，消息發(fā)送者要擁有消息接收者的公鑰
生成會(huì)話密鑰，作為對(duì)稱密碼的密鑰，加密消息
用消息接收者的公鑰，加密會(huì)話密鑰
將前2步生成的加密結(jié)果，一并發(fā)給消息接收者
發(fā)送出去的內(nèi)容包括
用會(huì)話密鑰加密的消息（加密方法：對(duì)稱密碼）
用公鑰加密的會(huì)話密鑰（加密方法：公鑰密碼）
5、混合密碼-解密
解密步驟（收到消息）
消息接收者用自己的私鑰解密出會(huì)話密鑰
-
再用第1步解密出來的會(huì)話密鑰，解密消息
image
6、混合密碼-加密解密流程
Alice >>>>> Bob
發(fā)送過程，加密過程
1.Bob先生成一對(duì)公鑰、私鑰
2.Bob把公鑰共享給Alice
3.Alice隨機(jī)生成一個(gè)會(huì)話密鑰（臨時(shí)密鑰）
4.Alice用會(huì)話密鑰加密需要發(fā)送的消息（使用的是對(duì)稱密碼加密）
5.Alice用Bob的公鑰加密會(huì)話密鑰（使用的是公鑰密碼加密，也就是非對(duì)稱密碼加密）
6.Alice把第4、5步的加密結(jié)果，一并發(fā)送給Bob
接收過程，解密過程
1.Bob利用自己的私鑰解密會(huì)話密鑰（使用的是公鑰密碼解密，也就是非對(duì)稱密碼解密）
2.Bob利用會(huì)話密鑰解密發(fā)送過來的消息（使用的是對(duì)稱密碼解密）
六、單向散列函數(shù)（One-way hash function）
單向散列函數(shù)，可以根據(jù)根據(jù)消息內(nèi)容計(jì)算出散列值
散列值的長度和消息的長度無關(guān)，無論消息是1bit、10M、100G，單向散列函數(shù)都會(huì)計(jì)算出固定長度的散列值
1、單向散列函數(shù)的特點(diǎn)
根據(jù)任意長度的消息，計(jì)算出固定長度的散列值
計(jì)算速度快，能快速計(jì)算出散列值
消息不同，散列值也不同
具備單向性
2、單向散列函數(shù)
單向散列函數(shù)，又被稱為消息摘要函數(shù)（message digest function），哈希函數(shù)
輸出的散列值，也被稱為消息摘要（message digest）、指紋（fingerprint）
常見的幾種單向散列函數(shù)
MD4、MD5
產(chǎn)生128bit的散列值，MD就是Message Digest的縮寫，目前已經(jīng)不安全
Mac終端上默認(rèn)可以使用md5命令
SHA-1
產(chǎn)生160bit的散列值，目前已經(jīng)不安全
SHA-2
SHA-256、SHA-384、SHA-512，散列值長度分別是256bit、384bit、512bit
SHA-3
全新標(biāo)準(zhǔn)
3、如何防止數(shù)據(jù)被篡改
4、單向散列函數(shù)的應(yīng)用 – 防止數(shù)據(jù)被篡改
5、單向散列函數(shù)的應(yīng)用 – 口令加密
七、數(shù)字簽名
想象以下場景
Alice發(fā)的內(nèi)容有可能是被篡改的，或者有人偽裝成Alice發(fā)消息，或者就是Alice發(fā)的，但她可以否認(rèn)
問題來了：Bob如何確定這段消息的真實(shí)性？如何識(shí)別篡改、偽裝、否認(rèn)？
解決方案
- 數(shù)字簽名
1、數(shù)字簽名
在數(shù)字簽名技術(shù)中，有以下2種行為
生成簽名
由消息的發(fā)送者完成，通過“簽名密鑰”生成驗(yàn)證簽名
由消息的接收者完成，通過“驗(yàn)證密鑰”驗(yàn)證
思考
如何能保證這個(gè)簽名是消息發(fā)送者自己簽的？
答案
用消息發(fā)送者的私鑰進(jìn)行簽名
2、數(shù)字簽名和公鑰密碼
數(shù)字簽名，其實(shí)就是將公鑰密碼反過來使用
3、數(shù)字簽名的過程
4、數(shù)字簽名的過程 – 改進(jìn)
5、數(shù)字簽名 – 疑惑
思考一下
如果有人篡改了文件內(nèi)容或者簽名內(nèi)容，會(huì)是什么結(jié)果？
結(jié)果是：簽名驗(yàn)證失敗，證明內(nèi)容會(huì)篡改數(shù)字簽名不能保證機(jī)密性？
數(shù)字簽名的作用不是為了保證機(jī)密性，僅僅是為了能夠識(shí)別內(nèi)容有沒有被篡改數(shù)字簽名的作用
確認(rèn)消息的完整性
識(shí)別消息是否被篡改
防止消息發(fā)送人否認(rèn)
6、數(shù)字簽名無法解決的問題
要正確使用簽名，前提是
用于驗(yàn)證簽名的公鑰必須屬于真正的發(fā)送者如果遭遇了中間人攻擊，那么
公鑰將是偽造的
數(shù)字簽名將失效所以在驗(yàn)證簽名之前，首先得先驗(yàn)證公鑰的合法性
-
如何驗(yàn)證公鑰的合法性？
證書image
八、證書（Certificate）
證書，聯(lián)想的是駕駛證、畢業(yè)證、英語四六級(jí)證等等，都是由權(quán)威機(jī)構(gòu)認(rèn)證的
密碼學(xué)中的證書，全稱叫公鑰證書（Public-key Certificate，PKC），跟駕駛證類似
里面有姓名、郵箱等個(gè)人信息，以及此人的公鑰
并由認(rèn)證機(jī)構(gòu)（Certificate Authority，CA）施加數(shù)字簽名CA就是能夠認(rèn)定“公鑰確實(shí)屬于此人”并能夠生成數(shù)字簽名的個(gè)人或者組織
有國際性組織、政府設(shè)立的組織
有通過提供認(rèn)證服務(wù)來盈利的企業(yè)
個(gè)人也可以成立認(rèn)證機(jī)構(gòu)
1、證書的利用
2、證書的注冊(cè)和下載
九、iOS簽名機(jī)制
iOS簽名機(jī)制的作用
保證安裝到用戶手機(jī)上的APP都是經(jīng)過Apple官方允許的不管是真機(jī)調(diào)試，還是發(fā)布APP，開發(fā)者都需要經(jīng)過一系列復(fù)雜的步驟
生成CertificateSigningRequest.certSigningRequest文件
獲得ios_development.cer\ios_distribution.cer證書文件
注冊(cè)device、添加App ID
獲得*.mobileprovision文件對(duì)于真機(jī)調(diào)試，現(xiàn)在的Xcode已經(jīng)自動(dòng)幫開發(fā)者做了以上操作
思考
每一步的作用是什么？
.certSigningRequest、.cer、.mobileprovision文件究竟里面包含了什么？有何用處？
1、iOS簽名機(jī)制 – 流程圖
2、iOS簽名機(jī)制 – 生成Mac設(shè)備的公私鑰
CertificateSigningRequest.certSigningRequest文件
就是Mac設(shè)備的公鑰
3、iOS簽名機(jī)制 – 獲得證書
4、ios_development.cer、ios_distribution.cer文件
利用Apple后臺(tái)的私鑰，對(duì)Mac設(shè)備的公鑰進(jìn)行簽名后的證書文件
5、iOS簽名機(jī)制 – 生成mobileprovision
6、iOS簽名機(jī)制 – 安全檢測
7、iOS簽名機(jī)制 - AppStore
如果APP是從AppStore下載安裝的，你會(huì)發(fā)現(xiàn)里面是沒有mobileprovision文件的
它的驗(yàn)證流程會(huì)簡單很多，大概如下所示
十、重簽名
如果希望將破壞了簽名的安裝包，安裝到非越獄的手機(jī)上，需要對(duì)安裝包進(jìn)行重簽名的操作
注意
安裝包中的可執(zhí)行文件必須是經(jīng)過脫殼的，重簽名才會(huì)有效
.app包內(nèi)部的所有動(dòng)態(tài)庫（.framework、.dylib）、AppExtension（PlugIns文件夾，拓展名是appex）、WatchApp（Watch文件夾）都需要重新簽名重簽名打包后，安裝到設(shè)備的過程中，可能需要經(jīng)常查看設(shè)備的日志信息
程序運(yùn)行過程中：Window -> Devices and Simulators -> View Device Logs
程序安裝過程中： Window -> Devices and Simulators -> Open Console
1、重簽名步驟
準(zhǔn)備一個(gè)embedded.mobileprovision文件（必須是付費(fèi)證書產(chǎn)生的，appid、device一定要匹配），并放入.app包中
可以通過Xcode自動(dòng)生成，然后在編譯后的APP包中找到
可以去開發(fā)者證書網(wǎng)站生成下載從embedded.mobileprovision文件中提取出entitlements.plist權(quán)限文件
security cms -D -i embedded.mobileprovision > temp.plist
/usr/libexec/PlistBuddy -x -c 'Print :Entitlements' temp.plist > entitlements.plist查看可用的證書
security find-identity -v -p codesigning對(duì).app內(nèi)部的動(dòng)態(tài)庫、AppExtension等進(jìn)行簽名
codesign -fs 證書ID xxx.dylib對(duì).app包進(jìn)行簽名
codesign -fs 證書ID --entitlements entitlements.plist xxx.app
2、重簽名GUI工具
iOS App Signer
https://github.com/DanTheMan827/ios-app-signer可以對(duì).app重簽名打包成ipa
需要再.app包中提供對(duì)應(yīng)的embedded.mobileprovision文件可以對(duì)ipa進(jìn)行重簽名
需要提供entitlements.plist、embedded.mobileprovision文件的路徑
3、動(dòng)態(tài)庫注入
可以使用insert_dylib庫將動(dòng)態(tài)庫注入到Mach-O文件中
https://github.com/Tyilo/insert_dylib用法
insert_dylib 動(dòng)態(tài)庫加載路徑 Mach-O文件
有2個(gè)常用參數(shù)選項(xiàng)
--weak，即使動(dòng)態(tài)庫找不到也不會(huì)報(bào)錯(cuò)
--all-yes，后面所有的選擇都為yes
insert_dylib的本質(zhì)是往Mach-O文件的Load Commands中添加了一個(gè)LC_LOAD_DYLIB或LC_LOAD_WEAK_DYLIB
可以通過otool查看Mach-O的動(dòng)態(tài)庫依賴信息
otool -L Mach-O文件
4、更改動(dòng)態(tài)庫加載地址
可以使用install_name_tool修改Mach-O文件中動(dòng)態(tài)庫的加載地址
install_name_tool -change 舊地址 新地址 Mach-O文件通過Theos開發(fā)的動(dòng)態(tài)庫插件（dylib）
默認(rèn)都依賴于/Library/Frameworks/CydiaSubstrate.framework/CydiaSubstrate
如果要將動(dòng)態(tài)庫插件打包到ipa中，也需要將CydiaSubstrate打包到ipa中，并且修改下CydiaSubstrate的加載地址2個(gè)常用環(huán)境變量
@executable_path代表可執(zhí)行文件所在的目錄
@loader_path代表動(dòng)態(tài)庫所在的目錄
