一種安全的前後端資料互動方案

加密方案：AES + RSA兩種加密方式混合使用，能夠實現資料的全程加密（無論是上傳，還是拉取）。

1、從客戶端動態生成16位AES密碼

2、使用第一步生成的AES密碼加密要上發的請求資料，由於AES加密後是byte[]資料，所以這裡還需要使用base64封裝一層以方便傳輸。格式大概如下：

{
    "key":"1234567890123456"
    "data":"5rWL6K+V5pWw5o2u"
}

3、使用RSA公鑰加密第二步生成的資料中的key，從而實現對key的保密，RSA加密後生成的二進位制資料同樣還需要再使用base64封裝一層以方便傳輸，客戶端的加密過程到這裡就基本完成，然後就可以將該請求傳送到服務端了。（RSA公鑰客戶端持有，RSA祕鑰服務端持有）

4、服務端收到了客戶端傳送過來的請求後，拿到key引數，即為RSA加密byte。

5、使用服務端持有的私鑰解密第4步獲取到的RSA加密byte。從而獲取到了第二步時候的資料，同時需要base64解碼data資料。也即拿到了AES的key。

6、獲取到AES的key後，便可以使用其來解密第5步中的data欄位，也就是客戶端的真正請求資料。進而做相關操作，並生成相應返回值。

7、服務端返回值生成後，同樣使用第5步獲取到的key進行加密，並得到返回的data（同樣的base64封裝）。與客戶端加密不同的是，服務端的返回中key欄位是客戶端的key欄位加了rsa簽名後的資料。格式大概如下。

{

    "key":"xxxxxxxxxx簽名後的key",
    "data":"5rWL6K+V5pWw5o2u"
}

8、使用服務端持有的私鑰對從客戶端傳過來的key的二進位制資料進行簽名（以防止中間人攻擊），然後將資料向客戶端返回。

9、客戶端拿到服務端的資料返回後，先使用本地持有的公鑰驗證簽名。然後base64解碼。

10、使用請求時候生成的key來解碼第9步驗證通過的資料，解碼後便得到了伺服器端的真正返回，至此流程大概就完成了。

最後我們來分析下，為什麼說，這套方案是比較安全的。

首先我們假設客戶端被反編譯，那他能獲取到什麼呢，一個動態生成的rsa加密key嗎，拿過來並沒有卵用。不過他能拿到我們的客戶端公鑰，拿到公鑰之後，他可以做兩件事情，1、偽造一個客戶端，傳送請求。 2、可以用來驗證任意請求是否來自我們的伺服器。 這兩種情況也就夠他自己一個人玩玩，都無法構成威脅。

其次，我們假設他通過抓包，獲取了到了我們某個使用者的請求全過程。接下來他可能首先分析上行資料，得到的是一個rsa加密後的資料，同樣我們假設他反編譯了我們的客戶端，並且拿到了公鑰，然而他還是解不了我們的rsa加密。上行資料無法破解，那他接下來就要來分析下行資料了，下行資料封裝比較簡單，而他也有我們的公鑰，完全可以驗證通過，並長驅直入直接拿到了我們的AES加密串，可惜啊，可惜，下行資料中並沒有AES的祕鑰啊。

總結一下，這套方案要被破解，思路只有通過其他途徑直接控制伺服器，然後再拿到我們的私鑰，那就死翹翹了。不過真到了伺服器都被人家攻陷了，那人家還拿你私鑰幹嘛，人家直接在上面掛個木馬來轉接客戶端請求不就可以了。綜上所述，這其實是一套相當完美的前後端資料互動方案。

儘管簡單，但是記錄下來，以防忘記。