作為后臺產品經理，常常需要進行外部系統的對接，在設計開放平臺接口過程中，往往會涉及接口傳輸安全性相關的問題，筆者在詳細的查閱大量資料后，結合自身的過往經驗，對于接口加密及簽名的相關知識做了一個系統性的總結，在方便自己查閱的同時也分享給大家做一些參考，說明不當之處歡迎指正。

接口安全性問題主要來源于幾方面考慮：

1. 防偽裝攻擊即請求來源是否合法？（案例：在公共網絡環境中，第三方 有意或惡意 的調用我們的接口）
2. 防篡改攻擊（案例：在公共網絡環境中，請求頭/查詢字符串/內容 在傳輸過程被修改）
3. 防重放攻擊即請求被惡意攻擊（案例：在公共網絡環境中，請求被截獲，稍后被重放或多次重放）
4. 防數據信息泄漏（案例：截獲用戶登錄請求，截獲到賬號、密碼等）

從實現接口安全考慮，下面分別就加密解密和簽名算法兩方面進行講解。

一、加密解密的概念與算法

1.1 為什么需要加密解密？

在客戶端與服務器進行交互時，必然涉及到交互的報文（或者通俗的講，請求數據與返回數據），如果不希望報文進行明文傳輸，則需要進行報文的加密與解密。

所以加密的主要作用就是避免明文傳輸，就算被截獲報文，截獲方也不知道報文的具體內容。

1.2 對稱加密，單向加密，非對稱加密的介紹與區別

加密分為對稱加密和非對稱加密：

• 對稱加密效率高，但是解決不了秘鑰的傳輸問題；
• 非對稱加密可以解決這個問題，但效率不高。（其中https是綜合了對稱加密和非對稱加密算法的http協議。）

1.2.1 對稱加密

采用單鑰密的加密方法，同一個密鑰可以同時用來加密和解密，這種加密方法稱為對稱加密，也稱為單密鑰加密。

即約定一個秘鑰，客戶端使用這個秘鑰對傳輸參數進行加密并提交至服務端，服務端使用同樣的秘鑰進行解密；

1）常用的對稱加密算法：

1. DES（Data Encryption Standard）：數據加密標準，速度較快，適用于加密大量數據的場合；
2. 3DES（Triple DES）：是基于DES，對一塊數據用三個不同的密鑰進行三次加密，強度更高；
3. AES（Advanced Encryption Standard）：高級加密標準，是下一代的加密算法標準，速度快，安全級別高，支持128、192、256、512位密鑰的加密；

2）算法特征：

1. 加密方和解密方使用同一個密鑰；
2. 加密解密的速度比較快，適合數據比較長時的使用；
3. 密鑰傳輸的過程不安全，且容易被破解，密鑰管理也比較麻煩；

3）加密工具：

openssl，它使用了libcrypto加密庫、libssl庫即TLS/SSL協議的實現庫等。TLS/SSL是基于會話的、實現了身份認證、數據機密性和會話完整性的TLS/SSL庫。

1.2.2 單向散列加密

單向加密又稱為不可逆加密算法，其密鑰是由加密散列函數生成的。單向散列函數一般用于產生消息摘要，密鑰加密等

1）常用的單向散列加密算法：

1. MD5（Message Digest Algorithm 5）：是RSA數據安全公司開發的一種單向散列算法，非可逆，相同的明文產生相同的密文；
2. SHA（Secure Hash Algorithm）：可以對任意長度的數據運算生成一個160位的數值。其變種由SHA192，SHA256，SHA384等；
3. CRC-32，主要用于提供校驗功能；

2）算法特征：

1. 輸入一樣，輸出必然相同；
2. 雪崩效應，輸入的微小改變，將會引起結果的巨大變化；
3. 定長輸出，無論原始數據多大，結果大小都是相同的；
4. 不可逆，無法根據特征碼還原原來的數據；

3）加密工具：

md5sum；sha1sum；openssl dgst

1.2.3 非對稱加密

非對稱加密即公鑰加密，只有私鑰能解密。私鑰加密，只有公鑰能解密。A首先生成一對公鑰和私鑰，然后將公鑰公開給別人加密，別人使用公鑰加密報文發送給A，A使用私鑰解密。反之相同。（發送給某人，用某人的公鑰加密。證明自己的身份，用自己的私鑰加密）

非對稱加密很少用來加密數據，速度太慢，通常用來實現身份驗證，發送方用對方的公鑰加密，可以保證數據的機密性（公鑰加密）；發送方用自己的私鑰加密，可以實現身份驗證（數字簽名）；

1）算法特征：

1. 秘鑰對，公鑰(public key)和私鑰(secret key)
2. 非對稱加密可以解決秘鑰傳輸問題，但效率不高。

基于非對稱加密的特性，又產生了以下兩個問題：

問題1：如何確認通信方證書的合法性呢？

借助于第三方機構：CA(Certificate Authority)。CA為每個使用公開密鑰的用戶簽發一個含CA簽名的證書，該證書的作用是證明證書中的用戶合法擁有證書中的公開密鑰，CA機構的數字簽名使得攻擊者不能偽造和篡改證書。

CA自身也擁有一個證書和私鑰。任何人都可以得到CA的證書，并用該證書驗證它所簽發證書有效性。

假設機構A向CA發出一個證書簽發請求：(證書簽發流程)

1. CA首先生成一對公鑰和私鑰，并自簽署一個CA證書certificate；
2. A向CA提供自己的基本信息和自己的公鑰；
3. CA先對A的基本信息和公鑰計算一個特征碼，然后再使用自己的私鑰對特征碼進行加密，加密生成的字符串（數字簽名）、A的公鑰、A的基本信息共同組成了CA簽發的數字證書；

有了CA簽發的數字證書，就可以通過CA來確認證書擁有者的身份，也就解決了通信中身份確認的問題。

問題2：通過CA實現了身份驗證，那如何保證數據的機密性呢？

保證數據的機密性，無非就是給數據加密，非對稱加密的加密速度慢，不適合對通信數據進行加密，而在實際通信過程中，身份確認完畢之后，通常使用對稱加密方式來加密數據。那如何協商對稱加密的秘鑰呢？通常有以下兩種方法。

方法1：秘鑰交換(Internet Key Exchange, IKE)算法

Diffie-Hellman算法秘鑰協商流程，假設A/B雙發進行通信，

1） A/B通信前，先生成p,g兩個大素數，作為生成數

2） A選定一個數x，B選定一個數y

3） A/B加密結果如下：

• A加密之后傳遞給B的內容: g^x%p –> B
• B加密之后傳遞給A的內容: g^y%p –> A

注意：互聯網上的用戶可以看到：p,g,g^x%p,g^y%p

4） A/B獲得到數據之后解密得到相同的結果

• A: (g^x%p)^x=g^xy%p
• B: (g^y%p)^y=g^xy%p

這樣A/B就協商出了一個共同的秘鑰g^xy%p，A/B雙方使用非對稱加密確認完身份之后，就可以是用該秘鑰加密通信數據了。

方法2：公鑰加密的方式協商秘鑰

1） A隨機生成一個字符串STR作為秘鑰，A先使用自己的私鑰加密STR得到STR1，A再使用B的公鑰加密得到STR2，A將STR2發送給B；

2） B接收到STR2，先使用B的私鑰解密，再使用A的公鑰解密，最后得到秘鑰STR；

這樣A、B就完成了秘鑰的協商，協商的秘鑰為隨機字符串STR。

常用的非對稱加密算法

• RSA：由 RSA公司發明，是一個支持變長密鑰的公共密鑰算法，需要加密的文件塊的長度也是可變的；既可以實現加密，又可以實現簽名
• DSA（Digital Signature Algorithm）：數字簽名算法，是一種標準的 DSS（數字簽名標準）；
• ECC（Elliptic Curves Cryptography）：橢圓曲線密碼編碼；

ECC和RSA相比，在許多方面都有對絕對的優勢，主要體現在以下方面：

1. 抗攻擊性強，相同的密鑰長度，其抗攻擊性要強很多倍。
2. ?計算量小，處理速度快。ECC總的速度比RSA、DSA要快得多。
3. 存儲空間占用小,ECC的密鑰尺寸和系統參數與RSA、DSA相比要小得多，意味著它所占的存貯空間要小得多。這對于加密算法在IC卡上的應用具有特別重要的意義。
4. 帶寬要求低，當對長消息進行加解密時，三類密碼系統有相同的帶寬要求，但應用于短消息時ECC帶寬要求卻低得多。帶寬要求低使ECC在無線網絡領域具有廣泛的應用前景。

1.3 加密算法

（1）DES加密算法

DES加密算法是一種分組密碼，以64位為分組對數據加密，它的密鑰長度是56位，加密解密用同一算法。

DES加密算法是對密鑰進行保密，而公開算法，包括加密和解密算法。這樣，只有掌握了和發送方相同密鑰的人才能解讀由DES加密算法加密的密文數據。

因此，破譯DES加密算法實際上就是搜索密鑰的編碼。對于56位長度的密鑰來說，如果用窮舉法來進行搜索的話，其運算次數為256。

隨著計算機系統能力的不斷發展，DES的安全性比它剛出現時會弱得多，然而從非關鍵性質的實際出發，仍可以認為它是足夠的。不過，DES現在僅用于舊系統的鑒定，而更多地選擇新的加密標準。

（2）AES加密算法

ES加密算法是密碼學中的高級加密標準，該加密算法采用對稱分組密碼體制，密鑰長度的最少支持為128、192、256，分組長度128位，算法應易于各種硬件和軟件實現。

這種加密算法是美國聯邦政府采用的區塊加密標準，這個標準用來替代原先的DES，已經被多方分析且廣為全世界所使用。

AES加密算法被設計為支持128／192／256位（/32=nb)數據塊大?。捶纸M長度）；支持128／192／256位（/32=nk)密碼長度，，在10進制里，對應34×1038、62×1057、1.1×1077個密鑰。

（3）RSA加密算法

RSA加密算法是目前最有影響力的公鑰加密算法，并且被普遍認為是目前最優秀的公鑰方案之一。

RSA是第一個能同時用于加密和數宇簽名的算法，它能夠抵抗到目前為止已知的所有密碼攻擊，已被ISO推薦為公鑰數據加密標準。

RSA加密算法基于一個十分簡單的數論事實：將兩個大素數相乘十分容易，但那時想要，但那時想要對其乘積進行因式分解卻極其困難，因此可以將乘積公開作為加密密鑰。

（4）Base64加密算法

Base64加密算法是網絡上最常見的用于傳輸8bit字節代碼的編碼方式之一，Base64編碼可用于在HTTP環境下傳遞較長的標識信息。

例如，在JAVAPERSISTENCE系統HIBEMATE中，采用了Base64來將一個較長的唯一標識符編碼為一個字符串，用作HTTP表單和HTTPGETURL中的參數。

在其他應用程序中，也常常需要把二進制數據編碼為適合放在URL（包括隱藏表單域）中的形式。此時，采用Base64編碼不僅比較簡短，同時也具有不可讀性，即所編碼的數據不會被人用肉眼所直接看到。

（5）MD5加密算法

MD5為計算機安全領域廣泛使用的一種散列函數，用以提供消息的完整性保護。

對MD5加密算法簡要的敘述可以為：MD5以512位分組來處理輸入的信息，且每一分組又被劃分為16個32位子分組，經過了一系列的處理后，算法的輸出由四個32位分組組成，將這四個32位分組級聯后將生成—個128位散列值。

MD5被廣泛用于各種軟件的密碼認證和鑰匙識別上。MD5用的是哈希函數，它的典型應用是對一段信息產生信息摘要，以防止被篡改。

MD5的典型應用是對一段Message產生fingerprin指紋，以防止被“篡改”。如果再有—個第三方的認證機構，用MD5還可以防止文件作者的“抵賴”，這就是所謂的數字簽名應用。

MD5還廣泛用于操作系統的登陸認證上，如UNIX、各類BSD系統登錄密碼、數字簽名等

二、簽名的概念與方法

2.1 為什么要簽名？

1） 在客戶端與服務器進行交互時，報文雖然加密了，但我們并不能確認這個報文是誰發過來的。例如，與第三方服務器B進行交互時，我方收到了一個已加密的請求，但我方并不能確認是服務器B發送的這個報文，此時我們可以用數字簽名的方式來進行驗證。作用：認證數據來源

2） 如果我方收到一個B服務器簽名的請求，那么B服務器也無法否認這個請求，因為帶有它的簽名，作用：抗否認性。

3） 我方收到一個B服務器簽名的請求，但我方并不能確認這個請求是否被篡改過（雖然報文加了密，也可能被篡改），此時即可用簽名，驗證簽名中的報文與傳過來的報文是否一致。作用：保證了數據的完整性

2.2 簽名算法過程

簽名的方式多種多樣，常見的形式如下：

2.2.1 APPKEY+簽名認證

1） 對除簽名外的所有請求參數按key做的升序排列,value無需編碼。（假設當前時間的時間戳是12345678）

例如：有c=3,b=2,a=1 三個參，另加上時間戳后， 按key排序后為：a=1，b=2，c=3，_timestamp=12345678。

2） 把參數名和參數值連接成字符串，得到拼裝字符：a1b2c3_timestamp12345678

3） 用申請到的appkey 連接到接拼裝字符串頭部和尾部，然后進行32位MD5加密，最后將到得MD5加密摘要轉化成大寫。

示例：假設appkey=test，md5(testa1b2c3_timestamp12345678test)，取得MD5摘要值 C5F3EB5D7DC2748AED89E90AF00081E6 。

風險在于一但appkey被別人獲取，即可仿照簽名，造成安全性問題

2.2.2 token+簽名認證

token+簽名認證的主要原理是：

1） 做一個認證服務，提供一個認證的webapi，用戶提交相關身份信息如供應商編碼，先訪問它

2） 服務端收到請求，去驗證相關身份信息，驗證成功后，服務端會簽發一個token，token一般可以存儲在緩存或數據庫中，以方便后面查詢出來進行驗證。再把這個 Token 發送給客戶端

3） 客戶端收到 token 以后可以把它存儲起來，比如放在 Cookie 里或者 Local Storage 里；客戶端每次向服務端請求資源的時候拿著相應的token以及請求的參數和服務器端提供的簽名算法計算出簽名后再去訪問指定的api，服務端收到請求，就獲取對應用戶的token和請求參數，服務器端再次計算簽名和客戶端簽名做對比，如果驗證通過則正常訪問相應的api，驗證失敗則返回具體的失敗信息.

安全的關鍵在于參與簽名的token，整個過程中token是不參與通信的，所以只要保證token不泄露，請求就不會被偽造。然后我們通過timestamp時間戳用來驗證請求是否過期，這樣就算被人拿走完整的請求鏈接也是無效的。

2.2.3 https模式

追求安全可以考慮https的雙向驗證模式 + 參數的sign簽名的規則雙重驗證達到安全的請求后臺

本文由 @不橈 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議