加密配置文件總結

應項目安全需求，現有工程中使用到的配置文件須要加密保護，提高產品安全性。

設計調研

考慮到是本地加密，先在現有工程中梳理一趟已有的加密方式，除去網絡模塊的非對稱加密方式以外，其餘涉及到關鍵敏感信息都採用了對稱加密。在工程中有多種實現，大體總結以下：

• 在已有的AES-ECB加密模塊的基礎上，增長輸出hex編碼的加密類。
• 異或加解密類，使用隨機生成的字符進行自定義的異或加密處理
• 在Windows內置的加密套件基礎上封裝的加密類
• Rijndael加密組件，該組件提供的接口支持ECB、CBC和CFB三種AES加密方式，提供的接口較完善。

本地配置文件的編碼方式有txt、xml和json三種格式，使用tinyxml來解析xml，使用jsoncpp來解析json格式，文本格式直接讀取。
在最處的設計中，嘗試把加解密的功能做爲基類，各個具體解析類做爲派生類，類圖以下：

在進行基礎功能的開發和測試時，發現加解密功能和具體的解析功能是正交獨立的，他們之間沒有父子關係，而應該是組合的關係。考慮到現有程序中已有的基於tinyxml更高一層級的封裝 XML 讀寫類，爲了複用已有代碼，在 讀取加密xml 的類中，應該組合 已有的XML讀寫類。

加解密功能由內部加密組件成員實現，讀寫功能轉發給已有的 CXMLFile來實現。

實現過程

肯定待加密文件列表

通常來講，服務器鏈接信息、本地功能配置信息、版本信息等文件須要加密保存。對於用戶可以設置並生成的文件，在設置時，再調用加密方法進行加密保存，而已有的設置文件無需加密保存，由於它已是密文的。

肯定影響範圍

有些特定的配置文件是須要按期從服務器更新的，也有些須要在升級時被覆蓋升級。所以，對於加密文件，在服務端下發時，也要採用同客戶端一樣的加密策略，保證客戶端可以正確解析加密文件。

若是待加密文件有被其餘組件讀取的場景，則在加密後要通知相關組件負責人採用加解密的方式來讀取待加密文件。

開發建議

在選擇密鑰和初始化向量時，雖然說能夠隨便輸入，經本人自測，發如今一些 在線AES加密解密
網站上，初始化向量設置中含有 % 和 & 兩種字符時，得不到正確的結果，提示 偏移量最少：16字節長度,而在海奼網網頁上，不會有這樣的問題。猜想多是在處理IV輸入時，對特殊字符考慮不完善致使的結果。爲了便於自測和測試人員迴歸驗證，建議初始化向量中不要包含 % 和 & 兩種字符。

因爲AES加密輸出的字符可能存在數字0的狀況，爲了便於後續的字符串操做，建議對輸出進行base64加密，在解密時，先進行base64解密，再進行aes解密，最後對輸出填充的內容進行去除，獲得原始明文。

測試建議

考慮到開發自測和後續測試人員的測試便利性，開發人員要提供與客戶端同樣的加解密文件測試工具，可以解析密文，也可以驗證加密算法的正確性。說到驗證加密算法的正確性，最簡單的就是同網上的在線AES加密網頁進行對比，這裏總結下本身遇到的一些坑。

在線AES加解密網址：

1. 在線AES加密解密
2. aes加密
3. 海奼網
4. Json在線
5. 腳本之家在線工具
6. AES在線工具

以上序號爲一、二、3的網站，對AES加密有較完善的參數輸入，4，5,6網站加密功能簡單，體驗很差。在網站一、二、3中，對於一樣輸入的加密參數，1和3網站輸出同樣，網站2輸出的不同。通過本身測試，本身程序中輸出的結果同一、3網站一致，所以，能夠判斷網站2內部計算是有問題的，不建議使用。建議使用 在線AES加密解密 和 海奼網 進行驗證。