序
寫這篇文章的開頭是因為一個同事問了我一個問題，
他說如果iOS證書過期了，我們debug包就打不開了，那么appstore下載的包會怎么樣呢？
關于證書的概念好像只有：從鑰匙串生成CSR文件、上傳到apple開發(fā)者中心、然后下一步、下一步、select...然后直接生成下載，過期了就重新配一下，感覺都知道又好像只知道這樣的一個過程，直到翻了翻資料（李明杰底層原理（上）），才把證書、描述文件、簽名...這些徹底弄明白了，如果你和我一樣，只知道一個配置，那建議還是看一看這篇文章。
來源：底層原理（上）
學習路線
加密解密 -> 單項散列函數(shù) -> 數(shù)字簽名 -> 證書 -> iOS簽名機制
一、關于加密
根據(jù)密碼的類型分類：對稱加密、非對稱加密
- 對稱加密：加密、解密使用相同的密鑰
- 非對稱加密：加密、解密使用不同的密鑰（公鑰、私鑰），也被稱為公鑰加密
- 對稱加密優(yōu)缺點
優(yōu)點：加密、解密速度快
缺點：不能很好地解決密鑰配送問題
對稱加密
- 非對稱加密特點、優(yōu)缺點
特點
- 加密密鑰：一般是公開的，因此該密鑰稱為公鑰
- 解密密鑰：由消息接收者自己保管，不能公開，因此稱為私鑰
- 公鑰、私鑰是一一對應的，不能單獨生成
優(yōu)點：能解決密鑰配送問題
缺點：加密、解密速度慢
密鑰配送
- 由消息的接受者，生成一對公鑰、私鑰
- 將公鑰發(fā)給消息的發(fā)送者
- 消息的發(fā)送者使用公鑰加密消息
非對稱加密
- 混合加密
- 將 ‘對稱加密’ 和 ‘非對稱加密’ 的優(yōu)勢相結(jié)合
優(yōu)點
- 解決了 ‘非對稱加密’ 速度慢的問題
- 通過 ‘非對稱加密’ 解決了 ‘對稱加密’ 的密鑰配送問題
說白了就是
- 用 ‘對稱加密’ 對傳輸數(shù)據(jù)進行加密；
- 用 ‘非對稱加密’ 對 ‘對稱加密’ 的密鑰進行加密。
二、單向散列函數(shù)
單向散列函數(shù)，又被稱為消息摘要函數(shù)（message digest function），哈希函數(shù)
- 特點及作用
特點
- 根據(jù)任意長度的消息，計算出固定長度的散列值
- 計算速度快
- 消息不同，散列值也不同
- 具備單向性
作用：防止數(shù)據(jù)被篡改?????
說白了，就是不管對多長的內(nèi)容進行計算，都能得到相同位數(shù)的一串數(shù)字，例：
MD5 ("123") = 202cb962ac59075b964b07152d234b70
MD5 ("123456789012345678901234567890") = a46857f0ecc21f0a06ea434b94d9cf1d
tips：可直接在Mac終端查看，使用該命令。
- md5 -s "xxxx"
- 常見的幾種單向散列函數(shù)
MD5、SHA-1、SHA-2、SHA-3等
三、數(shù)字簽名（注意：這里與數(shù)字證書區(qū)別對待）
- 消息發(fā)送者產(chǎn)生，別人無法偽造的一段數(shù)字串；（用私鑰加密消息的散列值，生成的結(jié)果）
- 同時也是對信息的發(fā)送者發(fā)送信息真實性的一個有效證明
如何能保證這個簽名是消息發(fā)送者自己簽的？
- 用消息發(fā)送者的私鑰進行簽名
如果有人篡改了文件內(nèi)容或者簽名內(nèi)容，會是什么結(jié)果？
- 簽名驗證失敗，證明內(nèi)容會篡改
數(shù)字簽名不能保證機密性？
- 數(shù)字簽名的作用不是為了保證機密性，僅僅是為了能夠識別內(nèi)容有沒有被篡改
數(shù)字簽名的作用
- 確認消息的完整性
- 識別消息是否被篡改
- 防止消息發(fā)送人否認
數(shù)字簽名無法解決的問題：中間人攻擊，如果遭遇了中間人攻擊，那么
- 公鑰將是偽造的
- 數(shù)字簽名將失效
數(shù)字簽名的過程.png
數(shù)字簽名的過程改進-I.png
數(shù)字簽名的過程改進-II
中間人攻擊-數(shù)字簽名無法解決的問題.png
四、證書
利用CA的私鑰，對其他人的公鑰生成數(shù)字簽名
作用：解決中間人攻擊（避免公鑰被攔截）???
- 密碼學中的證書，全稱叫公鑰證書（Public-key Certificate，PKC），跟駕駛證類似
- 里面有姓名、郵箱等個人信息，以及此人的公鑰???
- 并由認證機構(gòu)（Certificate Authority，CA）施加數(shù)字簽名???
證書主要內(nèi)容：個人信息、公鑰、權(quán)威機構(gòu)的數(shù)字簽名
用自己的話說：
就是CA用自己的私鑰對你的公鑰進行認證，其他人用CA的公鑰簽名的合法性
證書.png
注冊與下載.png
五、iOS簽名機制
作用：保證安裝到手機上的App都是經(jīng)過Apple官方允許的
蘋果充當了CA機構(gòu)
不管是真機調(diào)試，還是發(fā)布APP，開發(fā)者都需要經(jīng)過一系列復雜的步驟
- 生成CertificateSigningRequest.certSigningRequest文件
- 獲得ios_development.cer\ios_distribution.cer證書文件
- 注冊device、添加App ID
- 獲得*.mobileprovision文件
對于真機調(diào)試，現(xiàn)在的Xcode已經(jīng)自動幫開發(fā)者做了以上操作
思考
每一步的作用是什么？
.certSigningRequest、.cer、.mobileprovision文件究竟里面包含了什么？有何用處？
公鑰、私鑰持有者
簽名機制流程圖
- 如果從AppStroe下載的，里面沒有mobileprovision文件，只有 I 和 VII
解釋
1、Mac設備的公鑰
- 從鑰匙串生成CSR文件，就是生成公鑰的過程
2、生成證書
- 把公鑰（CSR文件）上傳到Apple后臺
- 利用Apple后臺的私鑰，對Mac設備的公鑰進行簽名后的證書文件
3、mobileprovision描述文件生成
- 選擇app id
- 選擇devices
六、重簽名
- 查看codesign用法
man codesign
- 重簽名步驟
1、準備一個embedded.mobileprovision文件（必須是付費產(chǎn)生的，aphid、device一定要匹配），并放入app中
- 可以通過Xcode自動生成，然后在編譯后的App包中找到
- 可以去開發(fā)者證書網(wǎng)站下載
2、從embedded.mobileprovision文件中提取出embedded.plist權(quán)限文件
- security cms -D -I embedded.mobileprovision > temp.plist
- /usr/libexec/PlistBuddy -x -c 'Print :Entitlement' temp.plist > embedded.plist
3、查看可用的證書（可以看到證書ID）
- security find-identity -v -p codesigning
4、對.app內(nèi)部的動態(tài)庫、AppExtension進行簽名
- codesign -fs 證書ID xxx.dylib
5、對.app包進行簽名
- codesign -fs 證書ID --entitlements entitlements.plist xxx.app
- 過程
1、當前app的devices中不包含設備b
2、重新生成一個embedded.mobileprovision，包含設備b,
3、用步驟二中的embedded.mobileprovision替換步驟一種的embedded.mobileprovision
1、查看Mac中的可用證書及ID
2、從embedded.mobileprovision文件中提取出plist權(quán)限文件
3、轉(zhuǎn)換成embedded.plist權(quán)限文件
4、將圖3生成的embedded.plist文件與待簽名的ipa放到一個文件夾進行簽名
5、將文件夾壓縮，修改類型為.ipa類型
