iOS逆向學習之十一（加密、簽名）

學前須知

虛擬人物設計

爲了方便咱們學習iOS的簽名機制，本文設置了4個虛擬人物，分別是

• Alice、Bob：相互通訊
• EVe：竊聽者
• Mallory：主動攻擊者

消息通訊與竊聽

• 未使用加密時，通訊雙方以明文通訊

• 可是這種通訊方式很容易被他人竊聽，從而被盜取機密信息

• 那麼如何防止信息被監聽呢？就須要對通訊信息進行加密操做。
  • 首先將明文加密成密文發送給接收方

- 接收方拿到密文後進行解密獲得明文數據

- 經過加密以後，就算有他人竊聽通訊數據，也只能獲得被加密後的密文數據

加密解密？

如何進行加密解密？

消息發送者使用密鑰進行加密

消息接收者使用密鑰進行解密

密碼的類型

根據密鑰的使用方式，咱們能夠將密碼分爲兩種

對稱密碼

對稱密碼就是加密和解密使用相同密鑰

經常使用的對稱密碼算法有三種

DES（Data Encryption Standard）

DES是一種將64bit明文加密成64bit密文的對稱密碼算法，密鑰長度是56bit。其實從規格上來講，密鑰的長度實際上是64bit，可是每隔7bit會設置一個用於錯誤檢查的bit，所以密鑰的長度實質上是56bit。
因爲DES每次只能加密64bit的數據，遇到較大數據時須要對DES加密進行迭代。並且因爲DES加密算法已經能夠在短期內破解，全部不建議使用。

3DES

3DES是將DES重複3次所獲得的一種密碼算法，也叫作3重DES，此算法目前還被一些銀行機構使用，可是處理速度不高，且有安全性問題。

• 3DES加密過程以下，將明文經過加密-解密-加密成密文

• 3DES解密過程以下，將密文經過解密-加密-解密成明文

以上加密解密過程當中，3個密鑰都是不一樣的，因此又稱爲DES-EDE3

• 若是以上過程的全部密鑰都相同，則結果和普通的DES等價，3次加密解密就沒有任何意義

• 若是密鑰一、密鑰3相同，密鑰2不一樣，則稱爲DES-EDE2

AES（Advanced Encryption Standard）

AES是用來取代DES稱爲新標準的一種對稱密碼算法，AES的密鑰長度有12八、19二、256bit三種。

密鑰配送問題

什麼是密鑰配送問題？

使用對稱密碼時，必定會遇到密鑰配送問題，具體以下圖

假設Alice將使用對稱密碼加密後的消息發送給Bob，Bob想要查看明文信息，就須要拿到Alice加密的密鑰，因此Alice同時要將密鑰發送給Bob，在發送密鑰的過程當中，可能會被Eve竊聽，Eve拿到竊取的密鑰和密文，一樣能夠解析獲得明文消息。

怎樣解決密鑰配送問題？

解決密鑰配送問題，有如下幾種方式

• 事先共享密鑰。也就是Alice和Bob事先私下共享密鑰，不能經過網絡傳輸。不過這種方式很是麻煩，不建議使用。
• 密鑰分配中心
• Diffie-Hellman密鑰交換
• 公鑰密碼。公鑰密碼是如今廣泛使用的一種方式，也是咱們主要學習的一種方式。

公鑰密碼（Public-key Cryptography）

公鑰密碼中，密鑰分爲加密密鑰和解密密鑰兩種，它們不是同一個密鑰，因此公鑰密碼又被稱爲非對稱密碼（Asymmetric Cryptography）

在公鑰密碼中：

• 加密密鑰是公開的，因此該密鑰稱爲公鑰（public key）。
• 解密密鑰，由消息接收者本身保管，不能公開，所以也稱爲私鑰（private key）。
• 公鑰和私鑰是一一對應，不能單獨生成的，一對公鑰和私鑰統稱爲密鑰對（key pair）
• 由公鑰加密的密文，必須使用該公鑰對應的私鑰才能解密。
• 由私鑰加密的密文，必須使用該私鑰對應的公鑰才能解密。

公鑰密碼解決密鑰配送問題

上面說到，密鑰配送問題能夠經過公鑰密碼來解決，具體解決流程以下：

• 首先，消息接收者生成一對公鑰和私鑰。
• 將公鑰發給消息發送者。
• 消息發送者用公鑰對消息進行加密。
• 消息發送者將加密後的密文發送給消息接收者。
• 消息接收者用私鑰對密文進行解密，獲得明文數據。

RSA

RSA是目前使用最普遍的公鑰密碼算法。它的名字是由3位開發者Ron Rivest、Adi Shamir、Leonard Adleman的姓氏首字母組成

混合密碼系統

對稱密碼和非對稱密碼的對比

• 對稱密碼不能很好的解決密鑰配送問題
• 公鑰密碼加密和解密速度比較慢，由於消息自己多大，加密後的密文就有多大，因此對於大批量的數據，加密解密速度過慢。
• 爲了解決密鑰配送問題，同時提高加密解密的速度。因而採起了將對稱密碼和公鑰密碼相結合的方式，取長補短。如今網絡上密碼通訊所用到的SSL/TLS都是運用了混合密碼系統。

混合密碼系統-加密

會話密鑰（session key）

• 會話密鑰是專門爲本次通訊隨機生成的臨時的密鑰，使用僞隨機數生成器來生成
• 會話密鑰做爲對稱密碼的密鑰，用來對消息進行加密，從而提升速度

加密步驟-發送消息

• 第一步，消息發送者須要拿到消息接收者的公鑰
• 第二步，生成會話密鑰，做爲對稱密碼的密鑰，將消息加密成密文
• 第三步，使用消息接收者的公鑰，來加密會話密鑰
• 第四步，將第二步和第三步生成的加密結果一塊兒發送給消息接收者

發送的內容包括

• 用會話密鑰加密的消息（使用對稱密碼加密）
• 用公鑰加密的會話密鑰（使用公鑰密碼加密）

混合密碼系統-解密

收到==消息發送者==發過來的消息以後，須要進行解密操做，具體步驟以下：

• 第一步，消息接收者用本身的私鑰解密出會話密鑰
• 第二步，用第一步解密獲得的會話密鑰解密消息，獲得明文數據

混合密碼系統-加密解密完整步驟總結

使用Alice做爲==消息發送者==，Bob做爲消息接收者

發送消息（加密）

1. Bob首先生成一對公鑰、私鑰
2. Bob將公鑰共享給Alice
3. Alice隨機生成一個會話密鑰（臨時密鑰）
4. Alice用會話密鑰加密須要發送的消息（對稱密碼加密）
5. Alice用Bob的公鑰加密會話密鑰（公鑰密碼加密、也稱爲非對稱密碼加密）
6. Alice將四、5步加密獲得的結果一塊兒發送給Bob

接收消息（解密）

1. Bob利用本身的私鑰解密會話密鑰（公鑰密碼解密、也稱爲非對稱密碼解密）
2. Bob使用會話密鑰解密發送過來的消息（對稱密碼解密）

單項散列函數（哈希函數）

單向散列函數能夠根據消息內容計算出散列值。而且散列值的長度和消息的長度無關，不管是1bit、10M、100G的消息，單向散列函數都會計算出固定長度的散列值。

單向散列函數的特色

• 根據任意長度的消息，計算出固定長度的散列值。
• 計算速度快，可以快速計算出散列值
• 消息不一樣，哪怕就相差1bit數據，散列值也不一樣

• 具有單向性，不可逆

經常使用的單向散列函數

單向散列函數又稱爲消息摘要函數、哈希函數。輸出的散列值也被稱爲消息摘要、指紋。

常見的幾種單向散列函數以下

MD四、MD5

產生128bit的散列值，MD就是Message Digest的縮寫，目前已經不安全

SHA-1

產生160bit的散列值，目前也不安全

SHA-2

SHA-25六、SHA-38四、SHA-512,散列值的長度分別爲256bit、384bit、512bit。散列值長度越大，安全性就越高

SHA-3

SHA3（Secure Hash Algorithm-3）是一種做爲新標準發佈的單向散列函數算法，用來替代在理論上已被找出攻擊方法的SHA-1算法。全世界企業和密碼學家提交了不少SHA-3的候選方案，通過長達5年的選拔，最終於2012年正式肯定將Keccak算法做爲SHA-3標準。

單向散列函數的應用

防止數據被篡改

• 防止文件被篡改，具體的作法是將文件經過單向散列函數獲得散列值。將散列值存放到安全的地方。若是一段時間後，文件被篡改，那麼拿到最新的文件，經過單向散列函數，獲得最新的散列值，同以前的散列值進行對比，就能夠肯定文件是否被篡改。

• 軟件被篡改。通常爲了分散通訊負荷，一些軟件公司會將本身的軟件放在鏡像站點上供用戶下載。那麼用戶如何判斷從鏡像站點下載的軟件是否被惡意篡改呢？通常軟件公司會將軟件經過散列函數獲得的散列值放在官網上，供用戶來對比，只要用戶下載的軟件獲得的散列值和官網一致，那麼就代表用戶下載的軟件沒有被惡意篡改過。例如軟件VNC，可點擊VNC官網查看。

口令加密

在App登陸時，通常都須要進行帳號和密碼的校驗，可是在數據庫中，保存的密碼通常都是進行SHA-2散列函數以後的散列值而不是明文密碼，因此在登陸時須要對用戶輸入的密碼進行散列算法，獲得散列值，再同數據庫保存的散列值進行比較，從而判斷密碼是否正確。

而且，因爲散列函數的不可逆，就算他人經過不正當手段獲取到數據庫中存放的密碼的散列值，也沒法獲取到用戶的真實密碼。這樣就大大增長了用戶數據的安全性。

數字簽名

其實，無論是使用以前的對稱加密、非對稱加密仍是混合密碼系統，都沒法驗證消息的真實性。也就是說消息的接收者沒法判斷這條消息是不是消息發送者所發出的。也有多是他人假裝成消息發送者發出的消息。那麼怎麼來驗證消息的真實性呢？經過數字簽名的方式來驗證。

數字簽名的兩種行爲

• 生成簽名。主要由消息發送者完成，經過「簽名密鑰」生成
• 驗證簽名。由消息接收者完成，經過「驗證密鑰」驗證

那麼，如何保證這個簽名是消息發送者本身籤的呢？答案就是使用消息發送者本身的私鑰進行簽名。上文中，咱們知道公鑰密鑰是公開的，全部人都能拿到的，因此在公鑰密碼中，任何人都能使用公鑰進行加密。

而在數字簽名中，任何人均可以使用公鑰來驗證簽名。

數字簽名和公鑰密碼的對比

數字簽名其實就是將公鑰密碼反過來使用

數字簽名的過程

普通數字簽名過程

• 首先，消息發送者生成一對公鑰、私鑰。
• 消息發送者將公鑰發送給消息接收者。
• 消息發送者用本身的私鑰對消息進行加密，獲得簽名信息。
• 消息發送者將消息和簽名一塊兒發送給消息接收者。
• 消息接收者使用消息發送者的公鑰對簽名信息進行解密，獲得簽名中的消息
• 消息接收者將解密獲得的消息和直接獲得的消息進行對比，若是二者一致，則說明簽名驗證成功

可是這樣的簽名過程速度很慢，由於簽名信息是經過加密原有的消息得到，若是消息大小是1M，加密後的簽名大小也是1M，最後發送給消息接收者的消息就是2M

改進數字簽名過程

在以前數字簽名的過程上使用單向散列函數進行改進。

• 首先消息發送者使用單向散列函數計算消息的散列值
• 消息發送者使用本身的私鑰對第一步獲取到的散列值進行加密，生成簽名信息
• 消息發送者將簽名信息和消息一塊兒發送給消息接收者
• 消息接收者使用消息發送者的公鑰對簽名信息進行解密，獲得解密後的散列值
• 消息接收者對消息進行單向散列計算，獲得散列值
• 消息接收者將簽名中解密獲得的散列值和直接進行散列函數獲得的散列值進行對比，若是一致則簽名驗證成功。

完整的簽名過程

數字簽名的做用

綜合以上幾點，能夠總結出數字簽名的做用：

• 確認消息是否完整
• 識別消息內容是否被篡改
• 防止消息發送者否定發送此消息

數字簽名的問題

• 首先思考一下，若是有人篡改了文件的內容或者是簽名的內容，會致使什麼結果？結果就是簽名驗證失敗，證實了文件內容被篡改。
• 再者，數字簽名的過程當中，將消息的明文直接發送給了消息接收者，沒法保證消息的安全性？數字簽名的做用並非爲了保證數據的機密性，僅僅是爲了可以識別消息內容有沒有被篡改。

要想正確的使用數字簽名，就必須驗證簽名的公鑰必須屬於真正的發送者。由於在消息發送者和消息接收者之間可能會遭遇中間人攻擊，具體攻擊步驟以下：

• 消息接收者將本身的公鑰發送給消息發送者。
• 中間人竊聽到了通訊的內容，獲取到了消息接收者發出去的公鑰。
• 中間人攔截消息接收者的公鑰，將本身的公鑰發送給了消息發送者
• 消息發送者誤覺得是消息接收者發送過來的公鑰，使用接收到的公鑰對消息進行加密，而後將密文發送給消息接收者。
• 中間人攔截到密文，使用本身的私鑰進行解密，獲取到明文消息。而後使用以前攔截到的消息接收者的公鑰對消息進行加密，將僞造的密文發送給消息接收者。
• 消息接收者接收到密文，用本身的私鑰進行解密，最終獲得明文消息。

以上的消息傳遞過程當中，消息發送者和消息接收者沒法察覺到中間人的存在，可是消息已經bei被泄漏了。

上面的通訊過程遭遇到了中間人的攻擊，會致使

• 公鑰是中間人僞造的
• 數字簽名失效

所以，在驗證簽名以前，首先得驗證公鑰的合法性。如何驗證公鑰的合法性呢？就須要經過證書。

證書

看到證書，咱們會聯想到駕駛證、畢業證等等，這些證書都是由權威機構認證的。在密碼學中的證書，全稱叫作公鑰證書（Public-key Certificate，PKC）。和駕駛證、學生證相似。

• 證書中有姓名、郵箱等我的信息，以及此人的公鑰
• 而且有認證機構（Certificate Authority，CA）施加數字簽名

CA就是可以認定「公鑰確實屬於此人」並可以生成數字簽名的我的或者組織

• 有國際性組織、政府設立的組織
• 有經過提供認證服務來盈利的企業
• 我的也能夠成立認證機構

證書的使用

證書的使用有如下幾個步驟：

1. 消息接收者生成本身的密鑰對 2.消息接收者在認證機構註冊本身的公鑰
2. 認證機構用本身的私鑰對消息接收者的公鑰施加數字簽名，而且生成證書
3. 消息發送者從認證機構那獲得帶有認證機構數字簽名的消息接收者的公鑰（證書）
4. 消息發送者使用認證機構的公鑰驗證數字簽名，確認消息接收者公鑰的合法性。
5. 消息發送者使用消息接收者公鑰加密消息，而且發送給消息接收者。
6. 消息接收者使用本身的私鑰解密密文獲得最終的消息

增長認證機構認證流程以後，消息發送者和消息接收者之間，就不存在公鑰的傳遞過程，消息發送者從認證機構獲取消息接收者的公鑰，這樣就杜絕了中間人攻擊致使公鑰僞造的問題

證書的註冊和下載流程以下

• 消息接收者到認證機構註冊公鑰
• 認證機構對消息接收者的公鑰進行數字簽名，生成證書保存到倉庫中
• 消息發送者從認證機構的倉庫中下載證書
• 消息發送者使用認證機構的公鑰對證書進行驗證，獲得消息接收者的公鑰