遊戲協議加密及身份驗證

時間如白駒過隙，一眨眼就過去了，本打算在2月份發這篇的，結果一直誤覺得2月有31日……

 

這一塊以前一直感興趣，終於在2月份爭取到機會去作這一塊的工做。前輩給我留下了一個鑑權的框架：

1. 客戶端鏈接服務器
2. 服務器將隨機數發給客戶端
3. 客戶端用客戶端私鑰加密，發回到服務器
4. 服務器端用客戶端公鑰解開密文，比對解開的隨機數是否與原來的一致
5. 若是一致，則客戶端發送隨機數到服務器，服務器用服務器端私鑰加密，將密文發送到客戶端；同時，產生新的隨機數，用於稍後對會話進行rc4加密，並將這個隨機數以客戶端公鑰加密，發送到客戶端。
6. 客戶端用服務器端公鑰解開密鑰，比對隨機數和本身發的是否相同，相同的話則用客戶端私鑰解開下一個包，取出用於rc4加密的key密文
7. 至此，雙方身份驗證完成，會話先進行壓縮，再經過rc4算法進行加密

 

在這裏，私鑰充當了一個身份的象徵，只要擁有私鑰，就認爲對方是授信客戶端。可能有朋友會問，若是客戶端被破解怎麼辦？我以爲安全專家道哥有個觀點很好，「安全的本質是信任的問題。設計任何安全方案，最終都必需要有一個東西是「假設能夠信任的」，只是看這個「可信任」的東西被攻擊成功的機率大小。若是不這麼作，則作不出任何的安全方案。」因此，考慮協議安全的時候，咱們只能選擇相信客戶端密鑰被安全的保管着。

 

回頭再看看這個方案，這裏用到了私鑰進行加密。熟悉ssh的同窗應該會聯想到其挑戰過程，ssh服務器是用客戶端公鑰對隨機數進行加密，再發送到客戶端的。公鑰加密和私鑰加密的區別是，在明文相同的狀況下，公鑰加密出來的密文每次都不同，而私鑰加密出來的密文是每次都相同的。示例代碼能夠參見： https://github.com/spin6lock/rsa_encrypt_and_decrypt_in_c 密文和明文老是一一映射，容易被碰撞攻擊，進而繞過加密過程。所以，私鑰加密多用於身份驗證，好比電子郵件的數字簽名，首先用md5對郵件明文進行信息摘要，而後用私鑰進行加密，公鑰是公開的，保證任何看到這封郵件的人均可以進行解密，獲取md5信息進行驗證，確保郵件沒有被纂改。

 

因而，我花了一週左右的時間修改了驗證流程。新的驗證流程以下：

1. 客戶端鏈接服務器
2. 服務器用客戶端公鑰加密隨機數，發給客戶端
3. 客戶端用客戶端私鑰解密，發回服務器
4. 服務器對比隨機數，不同的話就斷開鏈接
5. 客戶端用服務器端公鑰加密隨機數，發送到服務器
6. 服務器用私鑰解密，發送回客戶端
7. 客戶端驗證經過
8. 服務器用客戶端公鑰加密rc4會話所用密鑰，發送到客戶端
9. 客戶端用公鑰解開，接下來在rc4加密下上傳

 

接下來，想針對手機網絡模塊的工做特色進行協議優化。因爲手機受限於電量，網絡芯片工做時會有啓動，半速，全速，半速，設備待機這個速度曲線，若是可以在應用層對包進行打包發送，可以大大提升手機的待機時間，參見這篇開發指南。協議壓縮放在下一篇吧~