BitTorrent protocol encryption

Protocol encryption (PE), message stream encryption (MSE) or protocol header encrypt (PHE)[1] are related features of some peer-to-peer file-sharing clients, including BitTorrent clients. They attempt to enhance privacy and confidentiality. In addition, they attempt to make traffic harder to identify by third parties including internet service providers (ISPs).

MSE/PE is implemented in BitComet, BitTornado, Deluge, Flashget, KTorrent, Mainline, µTorrent, qBittorrent, rTorrent, Transmission, Tixati and Vuze. PHE was implemented in old versions of BitComet. Similar protocol obfuscation is supported in up-to-date versions of some other (non-BitTorrent) systems including eMule.[2]

Purpose

As of January 2005, BitTorrent traffic made up more than a third of total residential internet traffic,[3] although this dropped to less than 20% as of 2009.[4] Some ISPs deal with this traffic by increasing their capacity whilst others use specialised systems to slow peer-to-peer traffic to cut costs. Obfuscation and encryption make traffic harder to detect and therefore harder to throttle. These systems were designed initially to provide anonymity or confidentiality, but became required in countries where Internet Service Providers were granted the power to throttle BitTorrent users and even ban those they believed were guilty of illegal file sharing.

History

Early approach

Protocol header encryption (PHE) was conceived by RnySmile and first implemented in BitComet version 0.60 on 8 September 2005. Some software like IPP2P claims BitComet traffic is detectable even with PHE.[5] PHE is detectable because only part of the stream is encrypted. Since there are no open specifications to this protocol implementation the only possibility to support it in other clients would have been via reverse engineering.

Development of MSE/PE

In late January 2006 the developers of Vuze (then known as Azureus) decided to design and simultaneously implement a new, open protocol obfuscation method, called message stream encryption (MSE). It was included in Azureus CVS snapshot 2307-B29 on 19 January 2006.[6]

This first draft was heavily criticized since it lacked several key features. After negotiations between different BitTorrent developers a new proposal was written and then implemented into the Azureus and µTorrent betas within days. In µTorrent, the new protocol was called protocol encryption (PE).

MSE/PE in BitTorrent client versions

Operation

The BitComet PHE method used in versions 0.60 to 0.62 is neither published, nor is it compatible with MSE/PE.

MSE/PE uses key exchange combined with the infohash of the torrent to establish an RC4 encryption key. The key exchange helps to minimize the risk of passive listeners, and the infohash helps avoid man-in-the-middle attacks. RC4 is chosen for its speed. The first kibibyte (1024 bytes) of the output is discarded to prevent the Fluhrer, Mantin and Shamir attack.

The specification allows the users to choose between encrypting the headers only or the full connection. Encrypting the full connection provides more obfuscation but uses more CPU time.

To ensure compatibility with other clients that don't support this specification, users may also choose whether unencrypted incoming or outgoing connections are still allowed.

Supported clients propagate the fact that they have MSE/PE enabled through PEX and DHT.

Security

The estimated strength of the encryption corresponds to about 60–80 bits for common symmetrical ciphers.[19] Cryptographically, this effective key length is quite low, but appropriate in that the protocol was not designed as a secure transport protocol but rather as a fast and efficient obfuscation method. AES was proposed as the encryption method, but not adopted because it consumed too much CPU time. The required Diffie–Hellman keys to achieve a security equal to AES would have been much bigger or require elliptic curve cryptography, making the handshake more expensive in terms of used CPU time.

Effectiveness

Some ISPs are now using more sophisticated measures (e.g. pattern/timing analysis or categorizing ports based on side-channel data) to detect BitTorrent traffic. This means that even encrypted BitTorrent traffic can be throttled. However, with ISPs that continue to use simpler, less costly methods to identify and throttle BitTorrent, the current solution remains effective.

Analysis of the BitTorrent protocol encryption (a.k.a. MSE) has shown that statistical measurements of packet sizes and packet directions of the first 100 packets in a TCP session can be used to identify the obfuscated protocol with over 96% accuracy.[20]

The Sandvine application uses a different approach to disrupt BitTorrent traffic by making seeding impossible. Sandvine intercepts peer-to-tracker communication to identify peers based on the IP address and port numbers in the peer list returned from the tracker. When Sandvine later sees connections to peers in the intercepted peer lists, it may (according to policy) break these connections by sending counterfeit TCP resets. Various solutions exist to protect against Sandvine's attack including encrypting both peer-to-tracker and peer-to-peer communication, using Microsoft's Teredo so that TCP connections are tunneled within UDP packets, filtering TCP resets before they reach the TCP layer in the end-host, or switching entirely from a TCP-based transport to a UDP-based transport. Each solution has its trade-offs. Filtering out TCP resets typically requires kernel access, and the participation of the remote peer since Sandvine sends the reset packet to the local and remote peers.

Criticism

Bram Cohen, the inventor of BitTorrent, opposed adding encryption to the BitTorrent protocol. Cohen stated he was worried that encryption could create incompatibility between clients. He also stressed the point that the majority of ISPs don't block the torrent protocol. In 2006 Cohen wrote "I rather suspect that some developer has gotten rate limited by his ISP, and is more interested in trying to hack around his ISP's limitations than in the performance of the internet as a whole".[21] Many BitTorrent community users responded strongly against Cohen's accusations.[22] Cohen later added encrypted connections to his Mainline client[23] with the ability to receive but not originate them. Notably, when µTorrent was purchased by BitTorrent, Inc. and then became the next mainline release, the ability to originate encrypted connections was retained, but it became turned off by default. In an interview in 2007, Cohen stated "The so-called ‘encryption’ of BitTorrent traffic isn’t really encryption, it’s obfuscation. It provides no anonymity whatsoever, and only temporarily evades traffic shaping."[24]

Notes and references

  1. Usually referred to as the more proper protocol header encryption.
  2. "eMule protocol obfuscation (encryption)". emule-project.net. 2006-09-16. Retrieved 2010-03-11.
  3. "The Bittorrent Effect". Wired. 2007-05-30.
  4. "2009 Global Broadband Phenomena" (PDF). Sandvine.com. 2009-11-16.
  5. "News". IPP2P.org. 2006-01-04.
  6. "[Azureus-commitlog] CVS Snapshot Azureus2307-B29.jar has been released !". Sourceforge.net. 2006-01-19.
  7. "BitComet Client Release Notes". Bitcomet.com. 2006-03-07.
  8. "BitTornado T-0.3.18". Degreez.net forum. 2007-01-05.
  9. "Version Notes". BitTorrent.com. 2006-05-02. Archived from the original on 2006-06-13.
  10. "Changelog: Deluge 0.5.1 (11 June 2007)". Deluge-torrent.org. 2007-06-11. Archived from the original on 2008-04-01.
  11. SVN server. KDE.org. 2006-04-29.Subversion client required.
  12. "Encryption has been added !". KTorrent.pwsp.net forum. 2006-04-29. Archived from the original on 2007-06-05.
  13. "[Libtorrent-devel] LibTorrent 0.11.0 and rTorrent 0.7.0 released". Rakshasa.no mail archive. 2006-12-13.
  14. "Transmission 0.90 Released!". Transmission.m0k.org forum. 2007-10-24. Archived from the original on 2007-10-27.
  15. "[Azureus-commitlog] CVS Snapshot Azureus2307-B33.jar has been released !". Sourceforge.net. 2006-01-25.
  16. "Azureus : Java BitTorrent Client - Changelog". Azureus.sourceforge.net.
  17. "µTorrent 1.4.2 beta 435". uTorrent Announcements. 2006-01-29.
  18. "µTorrent 1.5 released". uTorrent Announcements. 2006-03-07.
  19. "RFC 3526 chapter 8". IETF.org.
  20. Hjelmvik, Erik; John, Wolfgang (2010-07-27). "Breaking and Improving Protocol Obfuscation" (PDF). Department of Computer Science and Engineering, Chalmers University of Technology. ISSN 1652-926X.
  21. Cohen, Bram (2006-01-29). "Obfuscating BitTorrent". Bram Cohen blog.
  22. "Debate over Protocol Encryption". uTorrent.com forum. 2006-02-04.
  23. "BitTorrent Mainline Version History". BitTorrent.com. 2006-10-15. Archived from the original on 2007-02-25.
  24. "Interview with Bram Cohen, the inventor of BitTorrent". TorrentFreak. 2007-01-17. Retrieved 2013-04-07.

External links

This article is issued from Wikipedia - version of the Thursday, April 28, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.