加密方案：AES + RSA兩種加密方式混合使用腿倚，能夠?qū)崿F(xiàn)數(shù)據(jù)的全程加密（無論是上傳昏滴，還是拉取）累颂。
1滞详、從客戶端動態(tài)生成16位AES密碼
2、使用第一步生成的AES密碼加密要上發(fā)的請求數(shù)據(jù)紊馏，由于AES加密后是byte[]數(shù)據(jù)料饥，所以這里還需要使用base64封裝一層以方便傳輸。格式大概如下：
3朱监、使用RSA公鑰加密第二步生成的數(shù)據(jù)中的key岸啡，從而實現(xiàn)對key的保密，RSA加密后生成的二進制數(shù)據(jù)同樣還需要再使用base64封裝一層以方便傳輸赫编，客戶端的加密過程到這里就基本完成巡蘸，然后就可以將該請求發(fā)送到服務(wù)端了。（RSA公鑰客戶端持有擂送，RSA秘鑰服務(wù)端持有）
4悦荒、服務(wù)端收到了客戶端發(fā)送過來的請求后，拿到key參數(shù)嘹吨，即為RSA加密byte搬味。
5、使用服務(wù)端持有的私鑰解密第4步獲取到的RSA加密byte。從而獲取到了第二步時候的數(shù)據(jù)碰纬，同時需要base64解碼data數(shù)據(jù)萍聊。也即拿到了AES的key。
6悦析、獲取到AES的key后寿桨，便可以使用其來解密第5步中的data字段，也就是客戶端的真正請求數(shù)據(jù)她按。進而做相關(guān)操作牛隅，并生成相應(yīng)返回值。
7酌泰、服務(wù)端返回值生成后媒佣，同樣使用第5步獲取到的key進行加密，并得到返回的data（同樣的base64封裝）陵刹。與客戶端加密不同的是默伍，服務(wù)端的返回中key字段是客戶端的key字段加了rsa簽名后的數(shù)據(jù)。格式大概如下衰琐。
8也糊、使用服務(wù)端持有的私鑰對從客戶端傳過來的key的二進制數(shù)據(jù)進行簽名（以防止中間人攻擊），然后將數(shù)據(jù)向客戶端返回羡宙。
9狸剃、客戶端拿到服務(wù)端的數(shù)據(jù)返回后，先使用本地持有的公鑰驗證簽名狗热。然后base64解碼钞馁。
10、使用請求時候生成的key來解碼第9步驗證通過的數(shù)據(jù)匿刮，解碼后便得到了服務(wù)器端的真正返回僧凰，至此流程大概就完成了。
最后我們來分析下熟丸，為什么說训措，這套方案是比較安全的。
首先我們假設(shè)客戶端被反編譯光羞，那他能獲取到什么呢绩鸣，一個動態(tài)生成的rsa加密key嗎，拿過來并沒有卵用纱兑。不過他能拿到我們的客戶端公鑰全闷，拿到公鑰之后，他可以做兩件事情萍启，1、偽造一個客戶端，發(fā)送請求勘纯。 2局服、可以用來驗證任意請求是否來自我們的服務(wù)器。 這兩種情況也就夠他自己一個人玩玩驳遵，都無法構(gòu)成威脅淫奔。
其次，我們假設(shè)他通過抓包堤结，獲取了到了我們某個用戶的請求全過程唆迁。接下來他可能首先分析上行數(shù)據(jù)，得到的是一個rsa加密后的數(shù)據(jù)竞穷，同樣我們假設(shè)他反編譯了我們的客戶端唐责，并且拿到了公鑰，然而他還是解不了我們的rsa加密瘾带。上行數(shù)據(jù)無法破解鼠哥，那他接下來就要來分析下行數(shù)據(jù)了，下行數(shù)據(jù)封裝比較簡單看政，而他也有我們的公鑰朴恳，完全可以驗證通過，并長驅(qū)直入直接拿到了我們的AES加密串允蚣，可惜啊于颖，可惜，下行數(shù)據(jù)中并沒有AES的秘鑰啊嚷兔。
總結(jié)一下森渐，這套方案要被破解，思路只有通過其他途徑直接控制服務(wù)器谴垫，然后再拿到我們的私鑰章母，那就死翹翹了。不過真到了服務(wù)器都被人家攻陷了翩剪，那人家還拿你私鑰干嘛乳怎，人家直接在上面掛個木馬來轉(zhuǎn)接客戶端請求不就可以了。綜上所述前弯，這其實是一套相當完美的前后端數(shù)據(jù)交互方案蚪缀。
