Terminology

Let's assume Alice already received some coins from a previous transaction and she now wants to send some to Bob.

In Bitcoin, each transaction has two important attributes. The scriptPubKey (also output or locking script) and the scriptSig (input/unlocking script). Alice decides at her sole discression what the scriptPubKey looks like. She uses a stack-based, Turing incomplete, Forth-like language called Script to define conditions that Bob needs to fulfill in order to spend these coins at another occasion. Original name for a scripting language, right?

Alice usually creates the scriptPubKey based on some data Bob sends her. We call that data an address and in a simple transaction you may think of it as a bank account number. This address is usually the main part of the scriptPubKey accompanied by some other Script instructions.

When the transaction's output is about to be spent, the other script – scriptSig – is the proof that the previous transaction's scriptPubKey conditions were met.

As the Bitcoin network evolved, number of standard scriptPubKey/scriptSig pairs occured and that's exactly what we will look into in this article.

P2PK (Pay-to-Public-Key)

Once a upon time when the original Bitcoin paper was drafted in 2008, there was only one single transaction type. The scriptPubKey is equal to the receiver's public key and the scriptSig is only a signature. The signature corresponds to a previous transaction's scriptPubKey's public key. The signature always corresponds to the previous transaction's scriptPubKey – that's how you prove you can spend it.

ScriptPubKey: <Bob's PublicKey> OP_CHECKSIG
ScriptSig: <Alice's Signature>

During the validation this is concatenated to < Signature > < Public Key > OP_CHECKSIG and executed^[1]. The OP_CHECKSIG checks the signature against the public key. If evaluted to true the transaction is valid.

The P2PK type is currently deprecated.

P2PKH (Pay-to-Public-Key-Hash)

In the previous P2PK transaction money are "send to a public key". This public key is therefore visible in the blockchain and the defence that prevents Eve to steal Bob's money is the ECDSA signature algorithm, the infeasibility of deriving a private key from the public key, in particular.

What happens though when cryptography fails us in future? The quantum computers are coming and the ECDSA's underlying discrete logarithm problem doesn't hold on quantum computers (see Shor's algorithm). The ones with posession of quantum computers would be theoretically able to derive private keys from the public keys visible in the blockchain. That sucks.

To mitigate this, Bitcoin creators came up with a simple improvement. Alice is provided only with a hash of Bob's public key. There are no known quantum algorithms defeating SHA-256 as of the moment. The scripts look as follows:

ScriptPubKey: OP_DUP OP_HASH160 <PublicKeyHash> OP_EQUALVERIFY OP_CHECKSIG
ScriptSig: <Signature> <PublicKey>

As you can see the public key is actually still visible on the blockchain (in the scriptSig). It needs to be, becuase the bitcoin nodes couldn't validate the signature otherwise. The major improvement is that the public key is in the scriptSig, meaning that it is published only if the coins are spent but not when received.

If you would like to understand why the script looks this way, have a look on how it gets evaluated. The book Mastering Bitcoin offers a nice step-by-step visualisation.

P2PKH is the most popular transaction type as up to date and represents the typical "Alice pays Bob" situation. If you've ever tried bitcoin, this is most likely what you have used. Bitcoin, however, offers more options and is not limited to such scenarios.

P2PKH addresses start with "1".

P2PSH (Pay-to-Script-Hash)

One of the more complicated scenario is the P2SH introduced in 2012 (BIP 16). P2PSH addresses start with "3".

ScriptPubKey: OP_HASH160 <redeemScriptHash> OP_EQUAL
ScriptSig: <Signature> <PubKey> <redeemScript>

A redeem script is yet another Script script. It defines the conditions instead of the scriptPubKey and is then incorporated into the scriptSig. Bob is responsible for creating the script but does not send it to Alice in full. He rather hashes it and sends the hash to Alice. Alice then includes the hash in the scriptPubKey.

Only during the spending Bob reveals the script in scriptSig. The redeem script can look in any way, an example of it is:

redeemScript: 2 <PubKey1> <PubKey2> <PubKey3> <PubKey4> <PubKey5> 5 OP_CHECKMULTISIG

This is also very common usage of P2SH, the multisig. Even though P2SH != multisig, it is its most popular usage today.

Note, that the terminology here gets really confusing. Suddenly, the scriptPubKey doesn't have a public key, but some weird hash instead and there is yet another script - the redeem script. The name scriptPubKey is a historic one (made sense with P2PK, didn't it?), input or locking script would be a better choice.

That being said, I'm sticking with scriptPubKey and scriptSig for clarity.

Multisig

Multisig transactions were a different type on its own, but were depracted and multisig transactions are currently done using P2SH.

OP_RETURN

Return transactions are used for dumping arbitrary data on the blockchain. It is not covered here further.

Your own

Note, that theoretically the scriptPubKey can be anything within the scripting limits. If you wish to create a transaction with some silly condition, you can! We could totally create a scriptPubKey with a condition 1 OP_EQUAL. The corresponding scriptSig is then just a number 1 to validate to true. With that scriptPubKey any user could then spend the coins by just providing 1, which doesn't seem very useful. In a similar manner, you could provide a script 1 2 OP_EQUAL forbiding anyone to further spend the money, therefore making it unspendable.

Although you can create such transaction you still have to wrap it in a redeem script and use a P2SH. Currently, only a set of standard transactions are allowed, most of them listed in this or the following article^[2].

Segwit

Segwit is covered in the following article.

SegWit's main intention was to remove transaction's signature out of the scriptSig (for a number of reasons) and move it to another designated field, called witness. This led to the introduction of two new types, which we cover in this second article.

SegWit transactions

A scriptPubKey that consists of a 1-byte push opcode followed by a data push between 2 and 40 bytes gets a special meaning. In another words, if a number between 0 to 16 is pushed onto the stack^[1] and then some more data between 2 and 40 bytes are, the upgraded nodes recognize this as a SegWit transaction.

A general native SegWit transaction looks like this:

ScriptPubKey: <1 byte witness version> <2-40 bytes witness program>
ScriptSig: (empty)
Witness: <witness items>

A non-upgraded node sees this as a ANYONE_CAN_SPEND transaction, because the scriptPubKey is just a push of some data and doesn't lay any conditions on the reciever. That's why the scriptSig can be empty and it is a valid tranaction on older nodes.

In SegWit world, the first value in the scriptPubKey is interpreted as a witness version and the second is a witness protected program, or just a witness program for short. The version flag denotes, how the witness program is evaluated. If a node encounters a witness version that it is unfamiliar with, it considers the transaction again as a ANYONE_CAN_SPEND, which allows further soft-fork compatible upgrades. As of today, there is only one witness version – version 0, so we are solely devoted to this version in this article.

When SegWit-aware node recognizes a witness version it supports, it interprets its witness program. In version 0 this starts of by checking the length of the witness program. If it is equal to 20 bytes, it is interpreted as a P2WPKH; if 32 bytes, it is a P2WSH. If it is neither 20 nor 32 bytes, it aborts. This is a version 0 convention hardcoded in the standard and the code itself.

P2WPKH (Pay-to-Witness-Public-Key-Hash)

This is the P2PKH described earlier, only SegWit upgraded.

ScriptPubKey: 0 <20-byte-PublicKeyHash>
ScriptSig: (empty)
Witness: <Signature> <PublicKey>

In P2WPKH the verification goes as follows:

• Check that the witness contains exactly two items
• Verify that HASH160 of the witness' public key is equal to the one present in the witness program
• Verify the signature as <Signature> <PublicKey> OP_CHECKSIG

The length of the witness program (20 bytes) indicates that it is a P2WPKH type. Again, this is an arbitrary definition, hardcoded into the standard. There is no OP_CHECKSIG operand in neither scriptPubKey nor witness, it is implicit by the definition of P2WPKH.

P2WSH (Pay-to-Witness-Script-Hash)

Now, remember P2SH? There is a native version of the very same principle for SegWit.

ScriptPubKey: 0 <32-byte-redeemScriptHash>
ScriptSig: (empty)
Witness: <witness items> <redeemScript>

RedeemScript: (any)

The first 0 indicates a witness version 0. The following 32 bytes indicates that this is a P2WSH type. The last item in the witness is the redeemScript. It is hashed with SHA256, compared against the 32-byte redeemScriptHash in the scriptPubKey, and then executed alongside with the witness items.

If this seems a little bit too abstract, have a look at the BIP141 example, which is a 1-of-2 multi-signature P2WSH.

Both P2WPKH and P2WSH are not using the traditional base58 addresses, but a new bech32 format as defined in BIP173. The format is not covered in the scope of this article, see the standard for more information.

Those two represent so called native SegWit transaction types. To allow non-SegWit wallets to generate a SegWit transaction two additional types were introduced. It uses a P2SH transaction as the cornerstone and includes either P2WPKH or P2WSH inside it. If a SegWit-aware node sees a P2SH which contains P2WPKH or P2WSH it interprets it in the native way.

P2WPKH nested in P2SH

ScriptPubKey: OP_HASH160 <20-byte-redeemScriptHash> OP_EQUAL
ScriptSig: <0 <20-byte-PublicKeyHash>>
Witness: <Signature> <PublicKey>

RedeemScript: 0 <20-byte-PublicKeyHash>

The P2SH redeem script is equal to 0 <20-byte-PublicKeyHash> which is exactly the same as P2WPKH scriptPubKey. The scriptSig is somewhat confusing, it is a canonical push of data, which contain another canonical push of data.

Let's have a look how this evalutes on older nodes. They see the scriptSig as a push of some data – 0014{20-byte-PublicKeyHash}. Older nodes consider it as a simple redeemScript, which contains only a push of some data, weird redeemScript right? Then the scriptPubKey is concatenated and it does a HASH160 of the redeemScript and compares the result against the redeemScriptHash. Hurray, they match! So older nodes see this as a wierd P2SH ANYONE_CAN_SPEND transaction with no signature, where two hashes are compared and that's it.

As far as the upgraded nodes are concerned, they see this as as a P2SH transaction as well, but they recognize the meaning of the pushed data (0014{20-byte-PublicKeyHash}) and they interpret it as a P2WPKH.

P2WSH nested in P2SH

This is quite similar to P2WPKH in P2SH. It just doesn't nest a P2WPKH but a P2WSH.

ScriptPubKey: OP_HASH160 <20-byte-P2SH-RedeemScriptHash> OP_EQUAL
ScriptSig: <0 <32-byte-P2WSH-RedeemScriptHash>>
Witness: <witness items> <P2WSH-RedeemScript>

P2SH RedeemScript: <0 <32-byte-P2WSH-RedeemScriptHash>>
P2WSH RedeemScript: (any)

The redeem script can be any valid Script script, the very same concept as in P2SH.

• dd the install iso to a usb disk, you may follow a tutorial on the Manjaro wiki
  • don't forget to type sd[letter] without a partion name, e.g. /dev/sdX not /dev/sdX1
• enter Lenovo's "BIOS" utility by pressing F2 during startup
• set SATA Controller to ACHI in Configuration tab
• set Boot Mode to Legacy Support in Boot tab
• save settings
• plug in your USB and press F12 during startup to enter Boot Manager
• select EFI USB Device

The Manjaro linux on the USB should boot up.

The extensions were firstly introduced in the RFC 3456 and later fully incorporated into the TLS itself. The client states which extensions it supports during the handshake (in the ClientHello message) and the server chooses which extensions to use at its sole discretion.

Many extensions are commonly used in the wild. In this article, I'm picking just a few out of many to introduce the concept and describe one of the most popular extensions today.

Server Name Indication [server_name]

This extension enables browsers to send the destination hostname as a part of a TLS handshake. Because of the shortage of IPv4 addresses, it's very common that multiple hosts are on the same IP address. In plain HTTP this is solved via the Host request header, which includes the same thing - the hostname.

Let's assume you want to make a HTTPS connection to www.susanka.eu. This website sits at IP 88.90.30.48 as does www.tsusanka.cz. The handshake starts and the server needs to provide a certificate, which is bound to the domain name. Since both tsusanka.cz and susanka.eu sit at the same machine with the same IP, how can it know which certificate to present?

And that's exactly where the Server Name Indication comes in handy. The client simply includes the hostname in the TLS handshake and the server knows right away which certificate to present.

Elliptic Curves capabilities [elliptic_curves]

This extension helps the client to specify what elliptic curves it supports. For example, the Elliptic Curves Key Exchange (ECDH) operates on some particular elliptic curve, where the mathematical voodoo occurs.

Let's spin up a TLS connection inside Firefox by simply visiting a HTTPS website. When inspected in Wireshark you can see that the ClientHello includes this extension and specifies which ECs it supports.

We can read from the image that our browser supports four elliptic curves. Let's dig a little bit more into the first one.

The ecdh_x25519 stands for the widely used Curve25519. On wikipedia and in the official RFC 7748 we can find that the curve is specified by the formula:

$$ y_2 = x_3 + 486662 x_2 + x $$

That it is a Montgomery curve, over the quadratic extension of the prime field defined by the prime number $$2^{255} − 19$$ and it uses the base point $$x=9$$

I always had a little bit of trouble understanding why it is this arbitrary curve and not another one. Why this prime number? Why multiply by 486662 and not another number that fit as well? Well, the answer to that is somewhat unsatisfactory. The choice of those constants and the form of the curve is simply to allow some performance tricks to achieve faster computations. Researchers simply found out that we can do some very specific tricks on this curve which makes it a nice fast curve to be used for cryptography. That's it, I'm afraid. Feel free to dive into the official paper.

Session tickets [session_ticket]

The TLS handshake is a costly operation. It requires two round-trips and on top of that, the cryptographic operations are CPU-exhaustive. TLS itself incorporates a mechanism called session resumption to abbreviate the handshake. The server assigns the session a unique ID and both the client and the server store the session details under such ID. During the next handshake, both sides simply state the ID and the connection is resumed using the stored data.

This mechanism, however, contains one big caveat – the server needs to store the session details for every client. That can add up to a lot of data! For that reason session tickets extension delegates the data-storing exclusively to the client.

The server sends all the session data (encrypted) to the client and the client stores it and sends it back to the server on resumption. No server-side storage is then needed whatsoever.

This was just a brief introduction into the extensions mechanism. I wanted to demonstrate that using the extensions you can extend or modify the TLS protocol as you desire.

Shortend version of my master thesis on Telegram:
https://www.susanka.eu/files/telegram-article.pdf

And the full thing:
https://www.susanka.eu/files/master-thesis-final.pdf

Slides from DEF CON 25:
https://www.susanka.eu/files/telegram-defcon-slides.pdf

Video from DEF CON 25 CryptoVillage:
https://www.youtube.com/watch?v=hvGyog57gwI

Slides from ROOTS 2017:
https://www.susanka.eu/files/telegram-roots-slides.pdf

Tools available on GitHub:
https://github.com/tsusanka/telegram-deobfuscator
https://github.com/tsusanka/telegram-extractor

Replay attack

A replay attack is an attack where an attacker sniffs data sent by the application and then resends them at a different time with a malicious intent. By doing so, the attacker can repeat any message without the user noticing. Curiously, the attacker does not actually know the message. A protection might be realized by implementing a message counter to keep track of the order the messages appear in.

To provide an example let's assume two parties: Alice and Bob (suprisingly) are exchanging messages in an encrypted manner. Alice asks a lot of questions and Bob answers lazily. Finally, Eve, an eavesdropper, listens to the encrypted communication. Eve is unable to read the messages, however, is able to take one of the Bob's answer and resends it later on.

If we further assume that Eve is able to identify Bob's "yes" answer (e.g. using social engineering, length of the encrypted message etc.), she is able to send the message anytime she desires and therefore respond to all Alice questions possitively!

Replay attack on Telegram

During my analysis of the official Android Telegram app (more articles on that here) I've examined some parts of the code in an attempt to discover potential vulnerabilities to exploit.

Amongst others I've analyzed how Telegram deals with the Replay attack issue outlined above. Telegram sends sequence numbers included in each message which should be later validated. The concerned code responsible for checking these numbers (file ConnectionsManager.cpp, line 728) is depicted in the following listing:

if (connection->isMessageIdProcessed(messageId)) {
	doNotProcess = true;
}
if (!doNotProcess) {
	// process
	addProcessedMessageId(messageId);
}

After the message decryption this block of code checks if the message was already processed. The class ConnectionSession holds an internal array of the already processed messages. If the message is accepted and processed, the message ID is then added into the array.

The behavior I believed might be exploitable concerns the addProcessedMessageId() function (ConnectionSession.cpp, line 55). The function checks the size of the array and if it exceeds 300, it erases the first 100 messages:

void addProcessedMessageId(messageId)
{
	if (processedMessageIds.size() > 300) {
		processedMessageIds.erase(processedMessageIds.begin(),
		processedMessageIds.begin() + 100);
	}
	processedMessageIds.push_back(messageId);
}

I came to a conclusion that after processing 300 messages, Telegram could accept older one again. I drafted the attack scenario as follows:

1. Sniff a message
2. Wait for 300 other messages
3. Replace the next message with the first one
4. Telegram processes the first message again

If Telegram would not provide any additional checks and actually delete the first 100 IDs, the message would be accepted twice.

Responsible Disclosure

The findings were reported to the Telegram security team on December 7th, 2016 with a kind request for comments. The first response from Telegram was received on 12th December 2016 and Telegram actually accepted my remarks.

According to the Telegram team the Android application (as opposed, allegedly, to the other clients, such as Telegram for iOS, Telegram Desktop etc.) does not perform one of the the security checks as is required by the protocol, defined in the Security Guidelines for Client Developers in particular.

Among other checks, the Security Guidelines require the message ID to be checked against the stored ones and Telegram performs that. However, it requires one more additional check – if the incoming message has an ID lower than all or equal to any of the stored IDs, such message is to be discarded. This action does indeed diminish the risk but Telegram for Android did not carry out this check.

The Telegram team further commented that this vulnerability does not allow the attacker to cause any severe damage because of the additional protection on the side of the Telegram API. Message actions (sending, editing, deleting, and changing read status), group membership, secret chats, and
other important areas are not affected ^[1].

Nevertheless, the Telegram team confirmed the attack would work for nonessential service updates like online or typing statuses. For example, the scenario would allow the attacker to alter the statuses of victim’s friends (as seen in the Android application, not in the Telegram network) or spoof the victim to see typing statuses from contacts not performing such action in reality.

I briefly reviewed these claims and concluded that the Java part of the Telegram application does indeed deal with additional identifiers, such as qts, pts and others. These values do seem to provide additional protection. It is important to mention that I did not perform any deeper research. Telegram promised this will be fixed in the next Android update – most likely in the 3.16 version which was released in early January 2017. Telegram also offered a financial reward for my findings.

Fix

I'm releasing this post quite late after the discovery. The reason is (besides me being lazy) that I wanted to see how Telegram will fix this. I was unfortunately unable to do so, because Telegram didn't update its GitHub repository since October 2016. That finally changed at the end of March 2017.

The developers indeed modified the addProcessedMessageId() and more importantly the isMessageIdProcessed() functions, you can see the code directly on GitHub.

The addProcessedMessageId() function now saves minProcessedMessageId value. This variable is set when the array of message IDs exceeds its 300 items capacity. It is set to the current lowest message ID stored in the array. All processed IDs have lower ID than this value and the check correctly asserts that the examines that.

I've reviewed the code and it seems correct. Great to hear Telegram fixed this properly.

Conclusion

The code quality is, to say it gently, very very doubtful. I think another article might follow on that, but it took me about a month just to familiarize myself with the code base. And it took a lot more effort to find the obfuscation method and this bug.

That being said, the Telegram security team took my report seriously and in a very professional manner (and let's be honest, this ain't no Heartbleed) and the communication was realized in a reasonable time frame. I'm not a Telegram fan, but they dealt with this issue with grace.

In case you want to intercept traffic as a Man-in-the-Middle intermediary we can use many popular tools such as Fiddler, Burp Suite or OWASP ZAP. These are great tools which are, however, built for the HTTP(S) protocol only. What software to use if you need to modify general non-HTTP traffic?

This was exactly my issue when I've analyzed the Telegram IM (see more articles). Telegram uses its own homebrew protocol MTProto directly on top of the TCP/IP suite. Since HTTP or HTTPS is not used at all, the tools mentioned above are not applicable.

The first tool I've found with similar capabilities was Ettercap, which I've already used to perform the MiM setup itself. It provides a simple filtering interface allowing to modify the data routed through. Unfortunately, Ettercap requires the filters to be written in its own language which is quite limiting and was insufficient for my needs at that time.

I finally came across two tools that seemed to solve my problems: Mallory and Trudy. The Mallory software may be found on github and there is a talk about it on youtube from the Black Hat USA conference in 2010. Some time passed since and the project seems to be abandoned. Let's have a look closer look on Trudy, which I've finally successfully used. Trudy was written by @kelbyludwig and its source code is available on github as well.

Trudy

The Trudy software can modify any TCP traffic and it is most likely inspired by the Mallory software mentioned in the previous section. As its documentation states, Trudy is "a transparent proxy that can modify and drop traffic for arbitrary TCP connections". All traffic is routed through Trudy which then applies so called modules to alter it.

Trudy modules are bulks of preprogrammed code to perform modifications desired by the user. Trudy provides an example stub of such a module, and users are encouraged to implement it. Because Trudy is written in Go, all modules are to be written in Go as well. To route the traffic and setup the environment properly, a prepared virtual machine is available.

Virtual machine setup

The VM installs all the required software and Trudy itself as well. Then it routes all the traffic in and out of Trudy using iptables. Trudy receives all the traffic, modifies it based on the used module and sends it back to internet as seen in the following Figure:

Trudy module

The implementation of a module for Trudy is quite straightforward. Trudy
calls specific methods in fixed order, each designed for one particular action.
The methods of a single module are as follows:

• Deserialize() converts the raw payload into a known structure of data
  (e.g. HTTP)
• Drop() if true is returned, the whole packet is discarded
• DoMangle() if true is returned, Mangle() is called
• Mangle() alters the payload
• DoIntercept() if true is returned, the data are sent to the Trudy in-
  terceptor 19
• DoPrint() if true is returned, PrettyPrint() is called
• PrettyPrint() prints data in a human friendly format
• Serialize() converts the data back to raw payload if it were previously
  deserialized
• BeforeWriteTo() actions taken before the data are written to one side
  or the other
• AfterWriteTo() actions taken after the data are written to one side or
  the other

Example

This dead simple example of a module cripples all incoming traffic received from an IP address 139.59.129.86 on port 80. It does so by rewriting the whole TCP/IP payload to zeros.

The main part of the module uses the DoMangle() and Mangle() functions:

func (input Data) DoMangle() bool {
	if input.ServerAddr.String() == "139.59.129.86:80" {
		return true
	}
	return false
}

func (input *Data) Mangle() {
	for i := range input.Bytes {
		input.Bytes[i] = 0x00
	}
}

The DoMangle() function limits the mangling to our specified IP address and Mangle() does the actual work.

Our test IP address was not chosen randomly, but rather corresponds to a domain of mine - nohttps.susanka.eu. After setting up Trudy with this example module, we can try to access the site via regular browser. The request will work fine but the response will get rewritten with zeros. The browser is obviously unable to parse the response and will eventually time out.

We may confirm this behaviour using WireShark. The picture below shows the modified response. The blue box is the TCP/IP payload - full of zeros as anticipated. The TCP/IP headers are left untouched (before the blue box).

You may find the whole module on my gist. It additionally enables console printing to give you an idea what's going on.

You can use Trudy for a numerous different use cases, it provides an easy interface to alter generic TCP/IP traffic on the air.

During my security analysis of the Telegram IM (full text available here) I've discovered Telegram obfuscates its traffic by re-encrypting everything with a prepended key. When I've prompted the Telegram Security team for comments, they responded that this measure is used to "counter some of the less sophisticated attempts at banning our service in certain countries". MTProto has a fixed structure where the auth_key_id value is always present at the beginning of the packet and therefore easily recognizable.

Let's have a look how the official Telegram for Android application obfuscates the traffic and why this is quite a naive idea.

When I started the analysis I wanted to check the network traffic Telegram produces. I've expected the data to correspond with the official documentation and to be in a form of:

I've extracted my own auth_key_id and I expected to see it amongst the sniffed data. However, the whole traffic seemed random and therefore likely encrypted, and no sign of the expected structure was present.

I've examined the code and after a few weeks of pain and despair I've discovered that the function responsible for this behavior is the Connection::sendData function. Before sending the data in the expected manner, Telegram encrypts them one more time with a random key attached in front of the data. Interestingly, the Counter block mode is used instead of the IGE endorsed by Telegram.

Technical details

To properly explain the obfuscation method I need to introduce my own terminology first to add a little more clarity because Telegram does not practise a great job in naming variables. Since the variables are explained in more detail in the following sections, reader may skip this list and use it as a reference later on.

• obf_enc_key_bytes 64 random bytes storing obf_enc_key and obf_enc_iv used for obfuscation. Telegram calls this simply bytes.
• obf_enc_key The key used for encryption to obfuscate data.
• obf_enc_iv The IV used for encryption to obfuscate data.
• obf_dec_key_bytes 64 bytes derived from obf_enc_key_bytes storing the server's encryption key and IV. Labeled in Telegram as temp.

Temporary encryption keys

The obfuscation process starts by generating 64 random bytes obf_enc_key_bytes. The first 8 bytes are unused. Bytes 8 – 39 are used as an encryption key and bytes 40 – 55 as an IV. Bytes 56 – 63 are composed of the last 8 bytes of obf_enc_key_bytes encryption of itself. It is unclear what are those bytes used for. The final obf_enc_key_bytes to be sent:

The length of the packet, yet again encrypted, and the real data to be transmitted as expected from the official documentation are then AES-CTR encrypted using the obf_enc_key and obf_enc_iv, and sent. All the other data in this TCP stream are encrypted using the same obfuscation key. When another connection is established, a new obf_enc_key_bytes is generated and the process repeats itself.

Besides the obf_enc_key_bytes setup, the very same function deals with setting up the obf_dec_key_bytes. This temporary key is used for decrypting the incoming traffic.

The obf_dec_key_bytes is derived from the obf_enc_key_bytes. 48 bytes are reversed from obf_enc_key_bytes, starting at position 8. This may be seen in the code snippet below. The first 32 bytes are then used as a key and the next 16 bytes as an IV for the incoming traffic decryption.

for (int a = 0; a < 48; a++) {
    obf_dec_key_bytes[a] = obf_enc_key_bytes[55 - a];
}

I believe Telegram server receives the obf_enc_key_bytes, tampers with them in a way described in this section and finally encrypts the response with obf_dec_key_bytes.

Deobfuscation program

As a part of the analysis I've written a simple C software, which removes the obfuscation. The program does not sniff the network data so you have to provide it with a file of sniffed data. I've used Wireshark to do this.

The program is also capable of describing the real MTProto traffic in case you use the master secret key auth_key as an argument. The key is obviously not available to an attacker rather this functionality is meant for study purposes if you want to examine what Telegram sends from your own device.

You may check it out on github. A readme file and an example is available there.

Why not TLS?

The obfuscation method is not officially documented, which makes sense if Telegram uses it to circumvent censorship. However, the reality of its functionality is doubtful at best. A more conventional approach would be much appreciated, such as the usage of SSL/TLS. If Telegram would use TLS, the traffic would then be indistinguishable from any other protocols using it, such as HTTPS.

Finishing on a personal note; I wasn't sure whether I should publish or not. Obviously, I don't want to make things easier for any oppressive regimes, on the other hand if a non-paid student can find this in a month or two does anyone actually believe the agencies can't or didn't already?

I came to a conclusion that I should publish these findings with a hope that Telegram might come up with a finer idea on how to do this or may get inspired by the Signal's technique.

IGE can be defined easily by the following formula:

$$ c_i = f_K(m_i \oplus c_{i-1}) \oplus m_{i-1} $$

where \(f_K\) stands for the encrypting function (like AES) with key \(K\)
and \(i\) goes from 1 to \(n\) – the number of plaintext blocks. Since picture is worth a thousand words here goes a diagram as well:

You may notice that for the first output block we need two ini-
tialisation values \(c_0\) and \(m_0\). Both are taken from the IV values described earlier. The original paper described \(m_0\) as a random block and \(c_0\) as its encrypted counterpart. The OpenSSL implementation however, uses a more general implementation where both \(m_0\) and \(c_0\) are provided by the user.