iOS 簽名機制

對稱加密(Symmetric Cryptography)

對稱加密指的是發送端和接收端使用同一種算法對 明文(Plain Text) 進行 加密(Encrypt) 或對 密文(Cipher Text) 進行 解密(Decrypt)

發送方先將將要發送的 明文 消息使用加密算法加密為 密文，然后將 密文 通過網絡發送至接收方。接收方在收到消息后，使用同一算法對 密文 內容進行解密，即將內容解密為 明文，這種情況下可以避免消息的直接明文傳輸，具有一定的安全性。加密解密使用的特定算法，我們一般稱之為 密鑰。

常見的對稱加密算法

• DES
• 3DES
• AES

使用對稱加密的方式進行消息傳輸需要解決密鑰配送問題，發送方和接收方使用同一密鑰進行加密解密，那在此之前，勢必要保證發送和接收雙方先拿到密鑰，而在密鑰的配送過程中，如果密鑰被第三方竊取，那么此后雙方發送的密文也能輕松被第三方解密。

非對稱加密(Asymmetric Cryptography)

在非對稱加密中，有 密鑰對(Key Pair) 的概念，一個 密鑰對 由 公鑰(Public Key) 和 私鑰(Private Key) 組成，私鑰 不公開，由發送或者接收方自己持有，公鑰 可公開，任何一方都可持有。

消息發送方先使用接收方生成的密鑰對中的公鑰對明文進行加密，將加密后的密文通過網絡發送至接收端，接收端收到密文后使用自己的私鑰進行解密，最終將密文解密為明文。

常見的非對稱加密算法

• RSA

混合加密(Hybrid Cryptography)

非對稱加密很好的解決了密鑰配送問題，但這種加密方式相對于對稱加密而言，加密解密速度較慢。針對此種情況，混合加密 方式應運而生，它結合了 對稱加密 和 非對稱加密 兩者的優勢，是一種既能解決密鑰配送問題，又能保證加密解密速度的新的加密方式

混合加密的實現方式：

消息發送方本地生成一個 隨機密鑰，使用隨機密鑰對明文進行加密，然后使用接收方 密鑰對 中的 公鑰 對本地生成的隨機密鑰進行加密，然后將使用隨機密鑰加密的密文和使用公鑰加密后的隨機密鑰一同發送至接收方，接收方在收到密文和加密后的隨機密鑰后，先使用 私鑰 對加密后的隨機密鑰進行解密，得到解密后的隨機密鑰，再使用這個隨機密鑰對密文進行解密，最終得到明文。后續接收雙方就可以使用這個隨機密鑰進行加密通訊了，在 HTTPS 這種網絡協議中就是使用這種混合加密方式實現的 安全套接字層(SSL/TLS)。

數字簽名

散列函數(Hash Function)

散列函數 是一種特殊的函數，又被稱為 摘要函數 或 哈希函數，通過它可以計算出消息的 散列值 （又叫消息摘要、哈希值或指紋）。相同的消息內容計算出來的散列值是相同的，不通的消息內容，盡管是很小的差別，計算出來的散列值都是有天壤之別的。散列值一般計算出來是一個固定長度的值，與消息的大小無關，1 bit 的消息和 1 TB 的消息計算出的散列值的長度是一樣的。散列函數具有 單向性，一個原始消息經散列函數計算后得到散列值，但這個散列值不可再通過散列函數計算出原始的消息。

常見的散列函數

• MD4、MD5
• SHA-1、SHA-2、SHA-3

散列函數一般用來校驗數據是否被篡改。一個常見的例子是軟件開發商一般將自己開發的軟件經散列函數計算之后的散列值公開在自己的網站上，用戶下載軟件后可以通過散列函數計算散列值是否與軟件廠商公布的散列值一致，以此來判斷自己下載的是否是正版軟件。另一個被廣泛應用的用途是口令加密，想象一個登錄場景，當用戶在網站上注冊一個賬號時，是否會將用戶的密碼使用明文進行存儲呢？答案顯然是否定的，如果是用明文存儲，一旦公司的數據庫泄露，那所有用戶的明文密碼將會泄露，這種情況將是災難性的。因此，業界一般采用的方式是使用散列函數，計算密碼的散列值，再將散列值存入數據庫中，下次用戶登錄時，只需要計算用戶輸入的密碼的散列值與數據庫中存儲的散列值是否一致，從而判斷用戶輸入的密碼是否正確，因為散列函數的單向性，即使數據庫泄露，也無法通過散列值反推出用戶的密碼。

數字簽名(Digital Signature)

數字簽名 是只有消息發送者才可以產生的無法偽造的，對消息真實性的一種證明。是一種結合和了 非對稱加密 技術和 數字摘要 技術（即上文中提到的散列函數）的簽名技術。

數字簽名的實現方式：

發送方將待發送的消息使用 散列函數 計算出散列值，然后使用自己的 私鑰 對 散列值 進行加密，生成的即為 數字簽名。然后將消息連同簽名一并發送至接收端。接收端在接受到消息和簽名后，首先使用 公鑰 對 數字簽名 進行解密，得到散列值，然后對接收到的消息使用散列函數計算散列值，比較簽名中的散列值和在接收端計算的散列值是否相等，來判斷接收到的消息是否被篡改。

數字證書

數字簽名 機制可以對發送的消息進行真實性認證，但是在網絡通信的過程中，容易被劫持并篡改，耳熟能詳的 中間人攻擊（Man-in-the-middle attack，MITM） 就是其中的一種。

中間人攻擊

所謂中間人攻擊，是指攻擊者與通訊的兩端分別創建獨立的聯系，并交換其所收到的數據，使通訊的兩端認為他們正在通過一個私密的連接與對方直接對話，但事實上整個會話都被攻擊者完全控制。我們平常在開發中使用 Charles 抓包工具進行抓包的時候，其實這個過程就是中間人攻擊。對于客戶端，Charles 偽裝成服務端，對于服務端，Charles 偽裝成客戶端，從而截獲雙方之間的通信訊息，并有可能進行篡改。

上圖中描述了一次中間人攻擊發生的過程：

首先發送者(Man)向接收者(Girl)發送請求發送者公鑰的請求，消息被中間人(Mid Man)截獲后，中間人偽裝成發送者，同樣向接收者發送了請求公鑰的消息，消息接收者接收到請求之后，返回了自己的公鑰，返回的信息再次被中間人截獲，中間人將發送者的公鑰保存下來，而將中間人自己的公鑰返回給了發送者。

發送者在自以為拿到了接收者公鑰，實際是中間人的公鑰后，通過將要發送的消息 Today is a good day 通過散列計算生成消息摘要(Digist)，并用自己的私鑰進行簽名，生成最后的簽名信息(Signature)，然后將消息和簽名一同發送給了接收者。

此時中間人又截獲了發送者的消息，中間人通過發送者的公鑰（如何獲取發送者的公鑰？其實在步驟 1 中就可以拿到發送者的公鑰，公鑰是公開的），驗證發送者的數字簽名，認證有效，然后將消息 Today is a good day 篡改為了 Today is a bad day，同樣通過中間人自己的私鑰，生成數字簽名，并將篡改后的消息和數字簽名發送給了接收者 。

接收者收到來自中間人的消息，此時接收者并不知道消息并非來自發送者，而是被中間人進行了截獲和篡改。使用中間人的公鑰對數字簽名進行驗證，驗證通過，最終得到 Today is a bad day 的消息。

中間人攻擊出現的原因是接收雙方在交換公鑰的過程中，被第三方截獲。從而導致消息傳輸的過程中，整個消息內容的控制權落到了中間人手中。怎樣保證公鑰在傳輸過程中不被篡改呢？

數字證書

數字證書（或公開密鑰認證）是用來證明公鑰擁有者身份的技術。公鑰擁有者將自己的公鑰發送給權威認證機構（CA），認證機構通過自己的私鑰，對認證者的公鑰進行數字簽名，然后將公鑰和數字簽名作為數字證書。接收者拿到證書后就可以通過 CA 的公鑰對證書進行驗證，如果公鑰和數字簽名計算后的散列值一致，則認為證書有效，即公鑰的擁有者身份得到確認，后續就可以通過公鑰進行會話。其主要流程如下：

iOS 簽名機制

為了保證安裝到用戶手機上的 App 是未經篡改的，安全的，iOS 系統采用了簽名機制，來保證應用的安全性，在應用編譯完成后，將會使用開發設備 Mac 的私鑰，對開發的 App 文件（包括可執行的二進制文件、圖片資源、xib 等資源文件）進行數字簽名。Mac 開發設備通過將自己的公鑰上傳至 Apple Developer 后臺，通過蘋果私鑰對 Mac 開發設備的公鑰進行數字簽名并生成證書文件，再通過配置應用的 App ID、Devices（設備的 UUID）、以及權限文件（entitlements）將上述文件再通過 Apple 的私鑰進行數字簽名，最后和簽名后的 APP 文件一起打包為一個 IPA 文件。詳細流程如下：

1、上傳 CSR 文件并生成證書文件

在鑰匙串中選擇 證書助理 > 從證書頒發機構請求證書

填寫郵箱和常用名稱后選擇存儲到磁盤

最后將生成一個 CertificateSigningRequest.certSigningRequest 文件

2、獲得 ios_development.cer / ios_distribution.cer 證書文件

在蘋果開發中心選擇 Certificates、Identifiers & Profiles

選擇證書類型

制作完成之后即可下載 ios_development.cer / ios_distribution.cer 證書文件

3、注冊 Device，添加 App ID，添加權限設置

添加 App ID

添加設備，注冊 Devices

4、獲得 *.mobileprovision 文件

選擇要制作的描述文件類型

選擇 Bundle Identifier

選擇對應證書

添加 Devices

命名描述文件后即可下載

下載的證書和描述文件雙擊即可安裝，可用于真機測試和 App 包上架。

整體流程

當應用編譯完成之后，就會通過開發設備的私鑰對 App 文件進行數字簽名，并將描述文件一起打入 IPA 安裝包中，當安裝到手機后，會驗證設備的 UUID，App 的 Bundle ID 以及權限描述是否與 mobile provison 中的一致，若一致，則通過 Apple 的公鑰驗證證書文件并拿到開發設備的公鑰，再去驗證 App 的可執行文件及相關資源的完成性，若驗證成功，則 App 可正常啟動。

個人博客

博客首發于 www.thatisawesome.club

總結

以上是生活随笔為你收集整理的『iOS开发』iOS 签名机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。