📜 ⬆️ ⬇️

Are there any more Telegram bookmarks?

As already mentioned in a recent post “ Is Telegram Safe? Or, as I was looking for a bookmark in MTProto,Telegram is a super secure messenger for smartphones that is so secure that a contest with an impressive prize was announced for its breaking. In that post, an effective attack on its protocol ( MTProto ) was described, the brief essence of which is that "the Telegram server can pick up a nonce in which the keys of users coincide even during a MITM attack and no one will know that they are listening to it " where nonce meant “random” data sequence involved in setting the key, it would seem, simply to increase entropy, but in reality it enabled the administrators of Telegram servers to easily and, most importantly, not detectable for users to perform Man-in-middle (MITM) attack on pr tocol to exchange keys. Some even found the code section responsible for the vulnerability - bookmark.

To the credit of Telegram, quite quickly it was recognized that the vulnerability is present and its correction was announced in the next version of the messenger, and the author is promised a reward - ibeatle writes: " from now on, zero will always come to zero, and in the next layer we will definitely remove this field from the scheme and explain in the documentation . " Meanwhile, in the description of protocol 1, we already see that the ill-fated ' xor nonce ' has disappeared, and the code has changed for the better. Pavel Durov said: " Just in case, I will explain to mass users: there was no data leakage, the vulnerability is closed, there is no danger ." All is well that ends well.

But has the vulnerability disappeared and has Telegram become protected from an undetectable MITM? There is an opinion that the administrators of Telegram servers still could not listen to users so that the verification of the keys will show that they match.

To do this, it suffices to use a degenerate key attack on the Diffie-Hellman (DH) protocol. The previous attack was on a part of the key establishment protocol algorithm that occurs immediately after DH, but there is also DH itself. In the documentation, there is an attempt to protect against some attacks on DH - it is prescribed to check the public parameters of p and g: "it ’s a safe 2048-bit prime, and that g generates a cyclic subgroup of order (p-1) / 2. " But nothing is said about checking the public keys g_a and g_b.
')
To carry out an attack, it is enough for the server to replace both parameters g_a and g_b by one (1) sent from clients A and B. In this case, both users as a result of the calculation of the private key will also have units. The server (and any other observing attacked session) knowing this property of the DH protocol will be able to calmly decrypt and read their messages. Although outwardly, everything will look "encrypted." Moreover, the key_fingerprint of this degenerate key will not be visually distinguishable from a normal complex key, since the fingerprint is not the key itself, but the sha1 cryptohash from the key.

To fix this vulnerability, a messenger would be enough to check that the g_a and g_b sent are not equal to one.

_________
1 Copy of the protocol description dated December 22: archive.is/Z8Keu

Source: https://habr.com/ru/post/207038/


All Articles