維基百科

BitTorrent協定加密

協定加密（Protocol encryption，PE）、訊息流加密（message stream encryption，MSE）或協定頭加密（protocol header encrypt，PHE）是部分對等網路檔案分享客戶端的特性，包括BitTorrent客戶端。它們嘗試增強隱私和保密性，並嘗試使第三方（如網際網路服務提供者）更難辨識流量頭部。

MSE/PE在BitComet、BitTornado（英語：BitTornado）、Deluge、Flashget、KTorrent、Mainline、µTorrent、qBittorrent、rTorrent、Transmission、Tixati和Vuze等軟體中有被實現。PHE在舊版本的BitComet中被實現。類似的協定混淆（英語：Obfuscation）在最新版本的非BitTorrent系統（包括eMule）中也有實現[1]。

目的

編輯

截至2005年1月，BitTorrent流量占據了住宅網際網路總流量的三分之一以上[2]，雖然這在2009年下降到不足20%[3]。一些網際網路服務提供者通過增加其容量來處理這種流量，另有一些服務商使用專用的系統來降速對等流量以降低成本。混淆和加密會使流量更難以被檢測和控制。這些系統的最初設計目的是匿名性或保密性，但在某些國家（或地區、運營商）因網際網路服務提供者限制BitTorrent流量或使用者而變成必需品，他們認為BitTorrent流量占用過多網路資源（增加運營成本）、干擾網路正常執行，或認為或限制「非法的」檔案分享。[來源請求]

歷史

編輯

早期方法

編輯

協定頭加密（PHE）由RnySmile（英語：RnySmile）構想並最先在2005年9月8日的BitComet 0.60中實現。一些軟體如IPP2P聲稱可以檢測到使用了PHP的BitComet流量[4]。PHE是可以被檢測的，因為只有部分流被加密。由於沒有此協定的開放規範，其他客戶端支援它的唯一方法是通過逆向工程。

MSE/PE的開發

編輯

2006年1月下旬，Vuze（當時稱為Azureus）的開發者決定設計並實現一個新的、開放的協定混淆方法，它被稱訊息流加密（message stream encryption，簡稱MSE）。該協定被包含在2006年1月19日的Azureus CVS快照2307-B29中[5]。

這份首稿受到了嚴重的批評，因為它缺乏幾個關鍵特徵。在幾名BitTorrent開發者磋商後，一份新的提案在幾天內被撰寫並實現到Azureus和µTorrent beta。在µTorrent中，新的協定被稱為協定加密（protocol encryption，簡稱PE）。

BitTorrent客戶端各版本中的MSE/PE

編輯
  • BitComet 0.63版本，發布於2006年3月7日。它移除了舊的協定頭加密並實現了新的MSE/PE以相容Azureus和µTorrent[6]。
  • BitTornado（英語：BitTornado）從T-0.3.18版本開始支援MSE/PE。截至2007年1月5日，該版本仍在下載頁面上標為「實驗性」[7]。
  • BitTorrent （Mainline）從2006年5月2日的4.9.2-beta開始支援MSE/PE[8]。
  • Deluge從Deluge-0.5.1開始支援MSE/PE[9]。
  • KTorrent在2006年4月29日的SVN版本535386中實現MSE/PE[10]。
  • rTorrent從rTorrent-0.7.0開始支援MSE/PE[11]。
  • Transmission從Transmission-0.90開始支援MSE/PE[12]。
  • Vuze（以前名為Azureus）自2006年1月25日（CVS快照2307-B33）起支援最終版標準[13]。Azureus 2.4.0.0於2006年2月10日發布，是首個支援MSE/PE的穩定版本客戶端。不過，Azureus的實現中存在瑕疵，會導致不正確的加密片段，從而雜湊檢查失敗。該瑕疵在2.4.0.2版本中被糾正[14]。
  • µTorrent在Azureus的beta 1.4.1 build 407發布4年後支援MSE/PE[15]。µTorrent的1.5（build 436）版本於2006年3月7日發布；它是首個支援PE的µTorrent穩定版本[16]。

操作

編輯

BitComet 0.60至0.62版本中使用的PHE方法即沒有發布，也不相容MSE/PE。

MSE/PE使用金鑰交換結合torrent的infohash建立一個RC4加密金鑰。金鑰交換有助於最小化被動監聽器的風險，而infohash有助於避免中間人攻擊。選擇RC4是為了速度更快。輸出的第一個kibibyte（1024位元組）被丟棄以防止Fluhrer, Mantin and Shamir attack（英語：Fluhrer, Mantin and Shamir attack）。

該規範允許使用者選擇僅加密報頭或者完全加密整個連接。加密整個連接提供更強的混淆能力，但也消耗更多的CPU時間。

為確保與不支援此規範的其他客戶端的相容性，使用者還可選擇是否仍允許未加密的傳入或傳出連接。

支援的客戶端通過節點交換（PEX）和分散式雜湊表（DHT）通告它們已啟用MSE/PE。

安全性

編輯

該加密方法若對應常用的對稱加密演算法，加密強度約為60-80位元[17]。在密碼學領域，這個有效的金鑰長度相當低，但該協定不是為安全傳輸而設計，而是作為一種快速並有效的混淆方法。AES曾被提出作為加密方法，但未被採用，因為會消耗太多的CPU時間。它需要迪菲-赫爾曼金鑰交換（Diffie–Hellman）金鑰來做到AES級別的安全性，而AES要做到會更大，或者需要橢圓曲線密碼學，使握手要使用較多的CPU時間。

效果

編輯

一些網際網路服務提供者正在使用更複雜的措施（例如模式/時量分析，或者基於信道側資料對埠進行分類）來檢測BitTorrent流量。這意味著加密的BitTorrent流量也可以被限流。但是，也有些服務商繼續使用簡單、便宜的方法來辨識和限流BitTorrent，因此當前的方案仍有效果。[來源請求]

對BitTorrent協定加密（也稱MSE）的分析顯示，封包大小的測量統計和TCP對談中前100個封包的封包方向可以被用來辨識混淆的協定，具有超過96%的準確性[18]。

Sandvine（英語：Sandvine）應用程式採用另一種途徑，通過使播種（Seeding）失效來瓦解BitTorrent流量。Sandvine截取對等端到跟蹤伺服器（tracker）的通訊並基於跟蹤伺服器返回的節點列表中的節點位址和埠號來辨識對等端。當Sandvine在之後看到已截取的對等端列表中的對等端的連接時，它可能（根據策略）傳送偽造的TCP重設來中斷這些連接。有多種方案來抗擊Sandvine的攻擊，包括對等端到跟蹤伺服器及對等端到對等端之間的通訊加密，使用微軟的Teredo使TCP連接隧道化為UDP封包，在終端主機的TCP層中過濾掉TCP重設包，或者完全從基於TCP的傳輸變為基於UDP的傳輸等。每個解決方案都各有利弊。過濾掉TCP重設通常需要核心存取權限和遠端節點的參與，因為Sandvine會將重設封包同時發給本地和遠端節點。[來源請求]

批評

編輯

BitTorrent的發明者布萊姆·科亨（Bram Cohen）反對將加密加入BitTorrent協定，他擔心加密可能導致客戶端之間的不相容，並還強調大多數ISP不封阻torrent協定。2006年他寫道：「我相當懷疑有些開發者受到了他的ISP的限制，並更有興趣破解他的ISP的限制，而不是整個網際網路的效能。」[19] 許多BitTorrent社群的使用者強烈反對Cohen的指責[20]。Cohen後來也添加了加密連接到他的Mainline客戶端[21]使其有接收能力，但不會如此傳送加密連接。[來源請求]

參考資料

編輯
  1. ^ eMule protocol obfuscation (encryption). emule-project.net. 2006-09-16 [2010-03-11]. （原始內容存檔於2009-09-25）. 
  2. ^ The Bittorrent Effect. Wired. 2007-05-30 [2016-12-05]. （原始內容存檔於2014-03-15）. 
  3. ^ 2009 Global Broadband Phenomena (PDF). Sandvine.com. 2009-11-16 [2016-12-05]. （原始內容 (PDF)存檔於2009-11-22）. 
  4. ^ News. IPP2P.org. 2006-01-04 [2016-12-05]. （原始內容存檔於2013-05-20）. 
  5. ^ [Azureus-commitlog] CVS Snapshot Azureus2307-B29.jar has been released !. Sourceforge.net. 2006-01-19 [2016-12-05]. （原始內容存檔於2019-09-24）. 
  6. ^ BitComet Client Release Notes. Bitcomet.com. 2006-03-07 [2016-12-05]. （原始內容存檔於2010-12-17）. 
  7. ^ BitTornado T-0.3.18. Degreez.net forum. 2007-01-05 [2016-12-05]. （原始內容存檔於2017-03-25）. 
  8. ^ Version Notes. BitTorrent.com. 2006-05-02 [2016-12-05]. （原始內容存檔於2006-06-13）. 
  9. ^ Changelog: Deluge 0.5.1 (11 June 2007). Deluge-torrent.org. 2007-06-11 [2016-12-05]. （原始內容存檔於2008-04-01）. 
  10. ^ Encryption has been added !. KTorrent.pwsp.net forum. 2006-04-29 [2016-12-05]. （原始內容存檔於2007-06-05）. 
  11. ^ [Libtorrent-devel] LibTorrent 0.11.0 and rTorrent 0.7.0 released. Rakshasa.no mail archive. 2006-12-13 [2016-12-05]. （原始內容存檔於2007-05-02）. 
  12. ^ Transmission 0.90 Released!. Transmission.m0k.org forum. 2007-10-24 [2016-12-05]. （原始內容存檔於2007-10-27）. 
  13. ^ [Azureus-commitlog] CVS Snapshot Azureus2307-B33.jar has been released !. Sourceforge.net. 2006-01-25 [2016-12-05]. （原始內容存檔於2019-09-24）. 
  14. ^ Azureus : Java BitTorrent Client - Changelog. Azureus.sourceforge.net. [2016-12-05]. （原始內容存檔於2006-03-20）. 
  15. ^ µTorrent 1.4.2 beta 435. uTorrent Announcements. 2006-01-29 [2016-12-05]. （原始內容存檔於2006-05-14）. 
  16. ^ "µTorrent 1.5 released" （頁面存檔備份，存於網際網路檔案館）. uTorrent Announcements. 2006-03-07.
  17. ^ RFC 3526 chapter 8. IETF.org. [2016-12-05]. （原始內容存檔於2017-01-18）. 
  18. ^ Hjelmvik, Erik; John, Wolfgang. Breaking and Improving Protocol Obfuscation (PDF). Department of Computer Science and Engineering, Chalmers University of Technology. 2010-07-27 [2016-12-05]. ISSN 1652-926X. （原始內容 (PDF)存檔於2016-12-04）. 
  19. ^ Cohen, Bram. Obfuscating BitTorrent. Bram Cohen blog. 2006-01-29 [2016-12-05]. （原始內容存檔於2006-02-07）. 
  20. ^ Debate over Protocol Encryption. uTorrent.com forum. 2006-02-04 [2016-12-05]. （原始內容存檔於2007-10-22）. 
  21. ^ BitTorrent Mainline Version History. BitTorrent.com. 2006-10-15 [2016-12-05]. （原始內容存檔於2007-02-25）. 

外部連結

編輯
取自「https://zh.wikipedia.org/w/index.php?title=BitTorrent协议加密&oldid=84728880」