三種保證URL地址可信的加密方式.doc

三種保證URL地址可信的加密方式近日接到一個需求，要求一臺資源服務器不僅在可以暴露在公網(wǎng)環(huán)境下的同時，還要保證只接受并處理可信的http訪問請求。需求場景如圖：為了訪問資源文件，用戶需要首先訪問某一臺Frontend Server進行用戶身份認證所有的用戶信息均由Frontend Server保存，F(xiàn)rontend Server認證通過后返回真實的重定向地址，用戶再根據(jù)重定向地址訪問Resource Server獲取資源文件。具體的使用場景正如上面所述，下面是我的思考過程.為了保證資源服務器收到的是一個可信的重定向地址，在安全性上有三點考慮：1. 重定向地址必須是可信的，即不可以被偽造，必須是由某一臺Frontend Server返回的重定向地址。 2. 為了防止盜鏈或資源被采集，每個Frontend Server返回的重定向地址應具有時效性。這個可以通過在鏈接地址上增加時間戳實現(xiàn)，但前提是該時間戳不可以被偽造。 3. 最后，在必要的情況下，還可以不去響應某一臺Frontend Server返回的重定向地址，即認為某一臺Frontend Server的重定向地址不可信、該Frontend Server不可信。這要求Resource Server能夠及時標示一臺Frontend Server為不可信服務器，并且該Frontend Sever服務器還不可偽造剩余可信服務器返回的重定向地址。 以上三點也可以總結(jié)為：防止公網(wǎng)用戶偽造URL地址，防止不可信Frontend Server偽造地址，防止過期URL地址訪問。由于Resource Server需要允許所有的公網(wǎng)用戶訪問，所以不能對Ip進行限制，并且一般情況下Resouce Server也不會與Frontend Server直接通信，因此只能通過URL的驗證方式。Frontend Server在生成每個URL的過程中中應包括Resource Server為每一個Frontend Server分配的賬戶fsId、密鑰fsKey以及記錄當前URL生成時間的時間戳fstime。fsid必須明文傳輸，fsKey做為加密運算的一個常量不可以明文傳輸?？梢韵氲降挠腥缦氯N：1.使用自定的加密函數(shù)生成加密簽名字符串。 加密函數(shù)將所有需要明文傳輸?shù)膮?shù)以及當前Frontend Server使用的密鑰fsKey做為參數(shù)并通過MD5轉(zhuǎn)換后生成加密簽名字符串，md5(encode(params,fsid, fskey, fstime)。重定向地址鏈接：/fsid=*&fstime=*¶ms=*&signmsg=md5(encode(params,fsid,fskey, fstime) Resource Server收到該請求后 根據(jù)fstime判斷該請求是否過期，過期請求直接返回。 根據(jù)fsid判斷該Frontend Server是否可信，如可信再根據(jù)fsid獲得服務器端保存的fskey。 使用相同的參數(shù)加密簽名過程，Resource Server根據(jù)params,fsid, fskey, fstime生成簽名字符串。 比較重定向地址傳來的簽名字符串signmsg與本地生成的簽名字符串是否相同，相同則認為是可信請求，否則為非法請求。 2.使用對稱加密算法保證HTTP通信可信。 Resource Server為每一臺Frontend Server分配不同的Des密鑰（fskey），F(xiàn)rontend Server使用對稱加密算法對拼接后的傳遞參數(shù)進行加密des(params|fstime)重定向地址鏈接：/fsid=*&desmsg= des(params|fstime) Resource Server收到該請求后 首先根據(jù)fsid判斷該Frontend Server是否可信，如可信再根據(jù)fsid獲得每個Frontend Server使用的Des密鑰fskey。 使用密鑰對desmsg信息解密，解密失敗直接返回。 根據(jù)解密后的fstime判斷是否過期，過期直接返回。 3.同時使用非對稱，對稱加密算法保證HTTP通信可信。 Frontend Server隨機生成key做為對稱加密算法的公鑰des(params|fskey|fstime)，并使用Resource Server提供的公鑰對key進行非對稱加密rsa(key)重定向地址鏈接：/fsid=*&rsamsg=rsa(key)&desmsg= des(params|fskey|fstime) Resource Server收到該請求后 首先根據(jù)fsid判斷該Frontend Server是否可信，如可信再根據(jù)服務器端保存的非對稱加密私鑰解密rsa(key)。 根據(jù)key解密des(params|fskey|fstime)。 通過fsid獲得服務器端保存的fskey，對比解密后的fskey，如果不相同則認為是Frontend Server偽造的非法請求。 根據(jù)fstime判斷是否過期，過期直接返回。 以上三種方法第一種會暴露所有的明文傳遞參數(shù)，第二種貌似最方便但卻有被攻破的危險，第三種有可能又會產(chǎn)生效率的問題。由于沒有進行過相關(guān)方面的開發(fā)，以上也是對平時了解有限的一些資料的總結(jié)，難免考慮不周。各位有更好的方法和建議嗎？第一種方法的突出問題是: 如果明文內(nèi)容和md5摘要同時都被篡改的情況，你將無法判斷是否可信。 因為md5的摘要算法很簡單，也很容易被別人猜到到你用的是什么摘要算法。第二種方法，因為你要使用的對稱加密算法，如何傳遞密鑰或者是事先配置好了密鑰嗎? 如果傳遞密鑰的話，要保證中途不被別人截獲，是很困難。第三種方法，因為采用了RSA非對稱加密，不存在第二種方法的密鑰被截獲的問題，因為公共密鑰本來就是可以公開的。但是問題也就隨之而來了。公共密鑰接收方如何確保接到的公共密鑰就是Resource Server發(fā)來的公共密鑰，而不是別人冒充的呢？至于生成密鑰的效率問題，可以把密鑰生成之后，緩存，可以根據(jù)具體要求進行定期更新。至于加密方法的效率的問題，可以用非對稱和對稱相結(jié)合的方式來解決。當然這些問題在有些情況下，是可以忽略的，要視情況而定。是這樣，以上三種方法都需要預先為每一臺Frontend Server分配fsid和fskey。fsid是Frontend Server的標示可以在URL參數(shù)中明文傳輸，fskey僅做為加密算法的一個加密常數(shù)參量是不允許明文傳輸?shù)?。所以第一種情況它可以偽造明文參數(shù)，但因為沒有fskey所以無法偽造參數(shù)簽名。第二種情況fskey就相當于對稱加密算法的密鑰，是提前分配好的，每次交互的時候不會傳遞該密鑰。第三種情況使用rsa保護隨機生成的des密鑰，同時des也會對fskey進行加密處理。最后，Resouce Server收到請求后都會根據(jù)fsid找到服務器端保存的fskey，然后再生成簽名字符串比較（第一種情況），或者對加密數(shù)據(jù)進行解密后進行fskey的比較。所以這里最關(guān)鍵的是fskey,一定要保證fskey不被竊取。但對于第二種方法由于des公鑰是提前分配好，并且可能是長期固定的，所以加密數(shù)據(jù)有可能被破解，知道了fskey后便可以偽造請求。第三種同理，雖然使用了動態(tài)的des公鑰，但是des加密后的數(shù)據(jù)也是可以被破解，并拿到fskey。無論是第二種情況采用的對稱加密方式，還是第三種情況采用的對稱加密、非對稱加密結(jié)合的方式都不能保證絕對安全。所以最終看來我只能周期性的修改預先分配給每一臺Frontend Server的fskey。如果前置服務器和后端服務器是可通訊的話，那就是個典型的單點場景了。謝謝大家的回帖，看來要保證網(wǎng)絡(luò)通信的絕對安全也不是件易事。參照grandboy的說法，應該選擇一種適合的方案解決一定密級要求下的網(wǎng)絡(luò)安全。所以解決方案也可以分為兩種，一種是適合于金融交易系統(tǒng)，要求在任何情況下都能保證網(wǎng)絡(luò)通信絕對安全的場景，但在這種情況下可能需要較高的成本投入。另一種情況是適合于普通互聯(lián)網(wǎng)應用環(huán)境，可以低成本投入，高效率運行，并能保證一定密級要求的次優(yōu)解決方案。具體說就是：1，理論上不保證每個時間點的絕對通信安全。2，可以被破解,但破解行為必須付出一定程度的時間成本。破解的時間成本也可以參考一些資料估算得出。3，在破解行為必須付出的時間成本內(nèi)Frontend Server和Resourc