1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

Identifying the Message Stream Encryption (MSE) protocol

From spid

Jump to: navigation, search

The Message Stream Encryption (MSE) protocol, which is used when running encrypted BitTorrent, is designed so that it should not be possible to detect the protocol by analysing the traffic. The reason is of course to make peer-to-peer (p2p) file sharing possible even when ISP's or Internet backbone operators are avtively trying to block or limit p2p traffic in their networks.

The MSE protocol is very cleverly designed so that it behaves randomly, both in terms of flow behaviour (such as packet sizes) and in terms of application data. This makes it almost impossible to detect the MSE protocol with methods such as flow statistics, which normally includes statistical measurements of packet sizes and packet inter-arrival times. Michal Zalewski's Fl0p is one example of an application that uses flow statistics, but there are several other solutions designed for traffic classification that are making use of flow statistics. A probably more widespread method of detecting protocols is to make use of static protocol signatures (or patterns) in the initial application-layer data packets of a session. The L7-filter is probably the best known and most widely used open source signature based protocol identification implementation. But the L7-filter, and other simular implementations, stand no chance of detecting the MSE protocol since there are no static fields or well-known byte values at fixed offsets in the MSE data.

There are, however, some distinctive properties that can be observed in the MSE protocol. Especially important is the initial Diffie-Hellman negotiation, which is performed first in each MSE session in order to establish a session encryption key.

  • After a completed 3-way TCP handshake the client starts by sending a Diffie-Hellman public key (G^Xa mod P) and some padding to the server. The size of this data will always be in the range of 96 to 608 bytes, but it can be divided into several packets (often in data sizes around 100 bytes per packet).
  • The server then responds with its Diffie-Helman public key (G^Xb mod P), which also is in the range of 96 to 608 bytes and can be divided into several TCP packets.
  • The client then sends some data, in the range of 124 to 636 bytes, to complete the Diffie-Helman transaction and to choose a encryption algorithm for the rest of the TCP session.

Some other apparent properties of the MSE protocol are:

  • The transfered data is all randomly looking (i.e. has a high bitwise entropy), except for the case when "no encryption" is choosen as the encryption algorithm after the Diffie-Hellman exchange.
  • High volumes of data and the data flows mostly in one direction in each individual session
  • The first 96 bytes from both the client and server will never have a value higher than the modulus value (P), which is:
0xFFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD1
29024E088A67CC74020BBEA63B139B22514A08798E3404DD
EF9519B3CD3A431B302B0A6DF25F14374FE1356D6D51C245
E485B576625E7EC6F44C42E9A63A36210000000000090563

A document written by the Azureus comminity regarding how to avoid traffic shaping (by ensuring that the application layer protocol of the TCP session does not get identified) is available here:

http://www.azureuswiki.com/index.php/Avoid_traffic_shaping#Escalation_of_the_crypto_settings

The systems that can detect the MSE protocol (also known as "Encrypted BitTorrent") do probably rely on inspecting the tracker session to see which port MSE is run over. This means that they rely on a side-channel technique to classify the session instead of doing the traffic classification based on the session itself.

The SPID algorithm, on the other hand, uses statistical measurements of various attributes in the actual MSE session to identify the protocol. The AccumulatedDirectionBytesMeter is designed to identify behaviour that is typical of the MSE protocol.

Personal tools