- Joined
- Feb 17, 2007
- Messages
- 678
- Reaction score
- 1,026
- Points
- 93
End-to-end encryption (E2EE) is considered a panacea for persistent attempts by hackers and law enforcement agencies to familiarize themselves with online correspondence. The meaning of E2EE often boils down to the fact that keys are stored only on interlocutor devices and do not get to the server ... but this is not entirely true. Let's see how things really are with E2EE, using the example of popular instant messengers.
Encryption in messengers
The study of Obstacles to the Adoption of Secure Communication Tools (PDF) pushed me to write this article. As its authors found out, "the vast majority of survey participants do not understand the basic concept of end-to-end encryption." Simply put, people usually choose the messenger with their heart and not their brain.
To begin with, E2EE has its own characteristics in each messenger. In Signal, it's almost exemplary. WhatsApp is formally the same as Whats Signal, with the exception of one very important point: changing the main key of a WhatsApp subscriber does not block sending messages to him. At most, you can enable useless notification (which is disabled in the default settings). In Viber, end-to-end encryption is inactive by default, and it only appeared in the sixth version. In Telegram, E2EE is also used only in secret chats, and they are implemented quite oddly.
The conflict between Roskomnadzor and Telegram generally created excellent advertising for the latter. Ordinary users now consider the creation of Durov a real thorn in the back of the special services (or a little lower), which can not do anything with a bulletproof innovative service. Telegram fans compare it with Signal and claim the superiority of the first.
However, there are no miracles in cryptography, and especially in applied. Many mathematically beautiful ideas turn out to be hopelessly spoiled by implementation, when convenience and accountability put above security and privacy (and this happens almost always).
Initially, the messengers used the OTR protocol (Off-the-Record). It uses symmetric AES encryption in CTR mode, the DH key exchange protocol and the SHA-1 hash function. The AES-CTR scheme provides the so-called "controversial" (in a good way) encryption and the possibility of denying authorship of the text if it is intercepted. You can always refer to the fact that the intercepted traffic itself changed the ciphertext so that it corresponded to another variant of decryption of the same length. For example, instead of “go get some bread”, it turned out “poison the queen” - this is technically possible, and such a property is specially laid down in the algorithm.
The OTR protocol authenticates the interlocutors and encrypts the correspondence between them. It is safe as long as the conversation participants regularly check each other’s public key fingerprints and resist attacks against other vectors (including social engineering).
The main disadvantage of OTR is that after sending a new key, you need to wait for confirmation from the interlocutor. If it is offline, then communication will be temporarily impossible. One solution was the Double Ratchet (DR) algorithm, developed five years ago by Trevor Perrin and Moxy Marlinspike at Open Whisper Systems. Today DR is used in Signal, WhatsApp, Viber and many other instant messengers that support end-to-end encryption by default or as a separate option (secret chats).
A simplified diagram of the Double Ratchet algorithm (source: signal.org). Alice and Bob begin the session by exchanging public keys
End-to-end encryption
The E2EE scheme uses a combination of public and private key cryptographic systems. It is obvious in general terms and quite complex at the level of detail. It uses a mass of interconnected keys, some of which are necessarily sent to the server and, moreover, are necessarily downloaded to it before the start of correspondence, so that it can be started at any time. Let's look at it in more detail.
You probably know the beginning of the scheme, since it is standard for all asymmetric encryption systems - a key pair is generated. This is necessary because single-key cryptosystems (such as AES) are too difficult to use in pure correspondence. They would have to somehow organize a secure channel for transmitting the key (for example, to meet in person), and then do it again each time it is changed.
Everything is just like in the usual PGP: there are two interlocutors (Alice and Bob), each of which generates its own key pair. Then they exchange public keys, keeping secret their paired secret. Public keys are transmitted over an open channel (for that they are public, albeit intercepted for health) and serve two purposes: they allow you to encrypt a message and verify its signature. Accordingly, secret keys are used to decrypt and generate a signature.
The term "message" is used here in a broad sense. The message can be text, a media file, or service metadata that the messenger exchanges with the server. Some of this data contains timestamps, client application status, and new keys.
Such a cryptosystem somehow works in e-mail, since it is a service for delivering individual encrypted messages of arbitrary length. Using it, the interlocutors are not required to be online at the same time. All messages are accumulated on the server and downloaded from it on demand after the user successfully passes authorization. Decryption takes place locally using secret keys that are not transmitted anywhere. Mail with PGP is popular, but it is far from perfect. Why? See the article “Alice and Bob in PGP Country”.
Unfortunately, in its pure form, an asymmetric encryption scheme is also not suitable for messengers, since these services are focused on intensive online correspondence in the form of a chain of short messages. They must be displayed in a strictly defined order, and the interlocutor can be offline at any time and disrupt the structure of the dialogue.
Also, encrypting many short messages with one key is a bad idea. In total, hundreds (if not thousands) of them are created per day of correspondence. In many messages, the amount of ciphertext is minimal and predictable (emoticon, sticker). They also have standard headers that simplify cryptanalysis.
The peculiarity of the correspondence in the messengers is that due to the typical metadata in an short time, the attacker can intercept a large amount of predictable ciphertext. Its lion's share will correspond to the well-known open text. If it is encrypted with one key, then a successful attack will compromise all previously written messages, and even those that the interlocutors will write in the future.
To prevent this from happening, messengers provide such properties as direct and reverse secrecy. They imply the inability to read messages sent earlier and written in the future, having only the current encryption key on hand. For this, multilayer encryption is used with the transition from asymmetric to symmetric cryptography and additional keys with different lifetimes.
Diffie, Hellman! Give three!
From open documentation it is known that in Telegram, an authenticated key distribution provides the classic Diffie-Hellman (DH) protocol. It creates a bridge between asymmetric (RSA) and symmetric (AES) encryption, enabling a certain number of interlocutors to conduct encrypted correspondence, transmitting only public keys over an open channel. For this, session keys are generated in it, which are a shared secret or a shared ephemeral key. It is calculated based on the secret key of one interlocutor and the public key of another. Ephemeral keys are authenticated by long-term public keys.
In DH, the transmission channel may not be protected from listening (passive surveillance), but it must be protected from spoofing attacks. If the attacker can substitute traffic (perform an active MITM attack), then the whole scheme goes to hell.
Therefore, for its Signal messenger, Open Whisper Systems uses the Diffie-Hellman triple conversion method X3DH with Curve25519 (Bernstein elliptic curve for fast DH) or X448. Other cryptographic primitives in X3DH use HMAC-SHA-256 and AES-256.
Extended Triple Diffie - Hellman protocol establishes a shared secret key between two parties that mutually authenticate each other based on public keys. Additionally, the keys are verified immediately after setting up the session and before starting the transmission of messages. This minimizes the risk of MITM attacks, making them very complex.
X3DH uses four types of keys, three of which are constantly changing:
Changing auxiliary keys in X3DH occurs according to the Double Ratchet algorithm. He replaced the OTR and introduced the concept of a chain, or pool, of keys. In case the interlocutor is offline, the creation of an OPK pool is provided. Several one-time ephemeral keys are uploaded to the server in advance and are consumed as you communicate. This allows the server to receive encrypted messages, authenticating their sender with a new key pair, even when the recipient is offline. If the OPK pool is exhausted, then the server uses a spare EK.
The name “double ratchet” is a reference to the device of the Enigma cryptographic machine with gears, which excluded the reverse movement and reuse of the previous values. The digital analogy is that DR is used to generate new ephemeral keys that encrypt the next message (or a small portion of messages). At the same time, the ephemeral keys are guaranteed to differ, do not repeat the previous ones and cannot be predicted for a reasonable attack time.
X3DH is based on the TextSecure protocol, which was later renamed Signal. In a pure or slightly modified form, the Signal protocol is used in the eponymous messenger, as well as in WhatsApp, Viber, and others. Developers can give the protocol their own names, but in essence it is the same X3DH with a varying set of hash functions, PRNGs and other cryptographic primitives.
Group Chat Problem
The organization of group chats in instant messengers is discussed in detail in the recent article “More is Less: On the End-to-End Security of Group Chats in Signal, WhatsApp, and Threema” (PDF). I will give the main conclusions from it.
Our systematic analysis revealed that the integrity of communications (represented by the integrity of all messages) and group membership (determined by the ability of group members to manage them) do not have end-to-end protection. In addition, we showed that reverse secrecy (a key security feature) is not preserved when using the Signal protocol for group chats.
Explanation: The cornerstone of end-to-end encryption is authenticated key distribution using the classic or enhanced DH protocol. It works only for two interlocutors, forming a common secret. It is expected that in instant messengers DH is not used in group chats, and the messaging structure in them is devoid of basic cryptographic properties.
Encryption in group chats. A - sender, B - receiver, G - user group
The authors show what manipulations a server controlled by an attacker can perform in group chats due to the lack of E2EE in them. They conducted their research on the example of Signal and WhatsApp, but it is unlikely that other messengers can expect this problem to have some elegant solution.
Oddities Telegram
With Telegram, everything is covered in a veil of secrecy. There is only partial information about the MTProto 2.0 protocol. His external audit was not performed, and the open source Telegram model is used in a very distorted form and exclusively for marketing purposes. Below I will explain why I think so.
Judging by the official description, all undelivered messages are temporarily (we hope) stored on Telegram servers, which are often scattered around the world and combined into a virtual cloud. They are synchronized with each other in order to organize and deliver messages to one or several (in the case of group chat) interlocutors in a certain order as soon as they appear on the network. Therefore, encryption is divided into two stages: in the client-server and server-server sections. This is a common scheme, but the strange thing about it is that direct client connections are never used at all.
In Telegram, traffic is transmitted through the servers even when you open a secret chat, for which it would be more logical to make a P2P connection. The conclusion is that without constant use of Telegram servers, communication in this messenger does not work at all. Other messengers can use their servers only at the initial stage - to compare the current IP addresses of the interlocutors and organize a direct connection between them. Telegram doesn’t know how, and it’s damn similar to MITM by design.
For some reason, all arguments about the strength of MTProto 2.0 revolve around the fact that the DH algorithm reliably protects against interception. This is not true. The Diffie-Hellman algorithm is just vulnerable to a MITM attack. Moreover, in the case of Telegram, it is probably further weakened at the PRNG level.
The problem is that the Telegram client application is guided by a very slurred entropy estimate. Instead of locally generating pseudo-random numbers and filtering out quality primes, the client requests them from the server. What kind of PRSP is used on the server, how successful primes it generates, and whether there are any mechanisms on the server to selectively send primes with certain properties to individual clients are unanswered questions. The client application only checks the sent random number, and it’s simplified, because for a thorough prime numbers test in a reasonable time the smartphone will not have enough computing resources.
Another common argument for Telegram security is open source. However, they do not have the source code for the server side, and the client code is usually not relevant. Telegram repositories are updated with a long delay (unless the truncated web version is more or less lively), and they always contain only old versions. There is not even an opportunity to check whether the source code really compiles what is now distributed as a finished distribution.
Therefore, talking about the messenger audit is practically pointless. While specialists dig around the old code for several months, a dozen new versions of Telegram will be released, where huge pieces of code will be rewritten. To make the entire encryption system vulnerable, it is enough to replace one byte - for example, one conditional branch.
The hackathons that Durov is happy with will not replace the audit, since they prove nothing. Their tasks create an artificial situation in which the attacking side has only one encrypted message. In real life there are no such restrictions and there are many other vectors for attacking the messenger.
A Thousand and One Vulnerabilities
Signal - one of the few instant messengers whose protocol passed an external audit (PDF). The report on its results is very voluminous, so I will quote the main conclusions in my translation.
Our analysis shows that [protocol] Signal satisfies standard cryptographic assumptions and security features. We did not find any serious flaws in its design, which is very encouraging. With actual use of Signal, uncertainties remain. Therefore, it is impossible to say whether [Signal] Signal always achieves its stated goals.
You need to be aware that the analysis of the messaging protocol is an important stage of the audit, but by no means the only component of security. Any messenger works in a real and very vulnerable environment. Usually it runs on a not the latest version of Android, in parallel with a hundred left-handed applications (some of which probably abuse permissions or even contain Trojan bookmarks), and the account itself is tied to a mobile phone number.
A huge gap lies in the fact that confirmation codes come in SMS. They can be intercepted through a known vulnerability in the SS7 cellular communication protocol. So the attacker will gain access to the entire correspondence, without knowing the encryption keys and not even trying to crack the Signal / Proteus / MTProto / other security protocol. The messenger server itself will change the key and helpfully decrypt the last correspondence (at least, undelivered messages). Even your sticker packs will recover. The main thing is convenience, right?
Another gaping hole in the security model is push notifications. Without them, you won’t know that you received a message until you manually launch the messenger. With them, you turn the server of push notifications into a legalized “man in the middle”. For example, for notifications to work in iMessage, it sends encryption keys to Apple servers. They already perform user authentication and (at least) decryption of message headers. Restore your Apple account on another device, and you’ll get everything as it was - up to correspondence and passwords from Wi-Fi. Almost the same situation with the servers Google and Microsoft. Or do you still believe in end-to-end encryption with reference to the mobile number and the main account on your smartphone?
The problem of unsafe key management and a large attack surface concerns all instant messengers in general. WhatsApp, Viber and many others allow you to create copies of correspondence (including cloud) and do not encrypt metadata (and sometimes the fact of a conversation is more important than its content). Signal is doing a little better, but I do not consider it an ideal messenger for a number of reasons:
As you can see, third-party and especially proprietary messengers are difficult to trust, even if they were recommended by Snowden, Assange and EFF. Therefore, some organize communication through their messenger - with open source and plug-ins. The OTR plugin is suitable for simple correspondence, but it does not support group chats. There are related protocols mpOTR and GOTR, in which this function is added.
One way or another, for collective communication it is more convenient to use the open XMPP protocol (Extensible Messaging and Presence Protocol), which was formerly called Jabber. XMPP translates as “Extensible Messaging and Presence Protocol,” a very long name. Openness means full accessibility of source codes. You can raise your XMPP server, not depend on anyone and pay nothing for it. There is also a lot of ready-made servers and clients for every taste - for example, desktop Pidgin and Xabber for Android.
Extensibility implies the ability to transfer not only text, but also data of a different type, as well as the addition of various functions and encryption schemes. For example, via XMPP it is easy to transfer voice messages, videos and files, if desired, encrypted them using TLS or PGP. Not so long ago, based on XMPP, the OMEMO extension protocol was created, which uses the same DR from Open Whisper Systems as in Signal and WhatsApp, but without the other drawbacks of the latter.
conclusions
Modern messengers claim end-to-end encryption support, but it often turns out that it is implemented with weirdness. In addition, there are many other holes in their code that were left accidentally or intentionally. The latter is much more likely when you consider how much money and labor of professionals was invested in their development. I try to strike a balance between comfort and the usual enjoyment of paranoia. I use different messengers (which are more convenient for my interlocutors), but I never conduct really private conversations through them. There are many open source alternatives for this.
Source
Encryption in messengers
The study of Obstacles to the Adoption of Secure Communication Tools (PDF) pushed me to write this article. As its authors found out, "the vast majority of survey participants do not understand the basic concept of end-to-end encryption." Simply put, people usually choose the messenger with their heart and not their brain.
To begin with, E2EE has its own characteristics in each messenger. In Signal, it's almost exemplary. WhatsApp is formally the same as Whats Signal, with the exception of one very important point: changing the main key of a WhatsApp subscriber does not block sending messages to him. At most, you can enable useless notification (which is disabled in the default settings). In Viber, end-to-end encryption is inactive by default, and it only appeared in the sixth version. In Telegram, E2EE is also used only in secret chats, and they are implemented quite oddly.
The conflict between Roskomnadzor and Telegram generally created excellent advertising for the latter. Ordinary users now consider the creation of Durov a real thorn in the back of the special services (or a little lower), which can not do anything with a bulletproof innovative service. Telegram fans compare it with Signal and claim the superiority of the first.
However, there are no miracles in cryptography, and especially in applied. Many mathematically beautiful ideas turn out to be hopelessly spoiled by implementation, when convenience and accountability put above security and privacy (and this happens almost always).
Initially, the messengers used the OTR protocol (Off-the-Record). It uses symmetric AES encryption in CTR mode, the DH key exchange protocol and the SHA-1 hash function. The AES-CTR scheme provides the so-called "controversial" (in a good way) encryption and the possibility of denying authorship of the text if it is intercepted. You can always refer to the fact that the intercepted traffic itself changed the ciphertext so that it corresponded to another variant of decryption of the same length. For example, instead of “go get some bread”, it turned out “poison the queen” - this is technically possible, and such a property is specially laid down in the algorithm.
The OTR protocol authenticates the interlocutors and encrypts the correspondence between them. It is safe as long as the conversation participants regularly check each other’s public key fingerprints and resist attacks against other vectors (including social engineering).
The main disadvantage of OTR is that after sending a new key, you need to wait for confirmation from the interlocutor. If it is offline, then communication will be temporarily impossible. One solution was the Double Ratchet (DR) algorithm, developed five years ago by Trevor Perrin and Moxy Marlinspike at Open Whisper Systems. Today DR is used in Signal, WhatsApp, Viber and many other instant messengers that support end-to-end encryption by default or as a separate option (secret chats).
A simplified diagram of the Double Ratchet algorithm (source: signal.org). Alice and Bob begin the session by exchanging public keys
End-to-end encryption
The E2EE scheme uses a combination of public and private key cryptographic systems. It is obvious in general terms and quite complex at the level of detail. It uses a mass of interconnected keys, some of which are necessarily sent to the server and, moreover, are necessarily downloaded to it before the start of correspondence, so that it can be started at any time. Let's look at it in more detail.
You probably know the beginning of the scheme, since it is standard for all asymmetric encryption systems - a key pair is generated. This is necessary because single-key cryptosystems (such as AES) are too difficult to use in pure correspondence. They would have to somehow organize a secure channel for transmitting the key (for example, to meet in person), and then do it again each time it is changed.
Everything is just like in the usual PGP: there are two interlocutors (Alice and Bob), each of which generates its own key pair. Then they exchange public keys, keeping secret their paired secret. Public keys are transmitted over an open channel (for that they are public, albeit intercepted for health) and serve two purposes: they allow you to encrypt a message and verify its signature. Accordingly, secret keys are used to decrypt and generate a signature.
The term "message" is used here in a broad sense. The message can be text, a media file, or service metadata that the messenger exchanges with the server. Some of this data contains timestamps, client application status, and new keys.
Such a cryptosystem somehow works in e-mail, since it is a service for delivering individual encrypted messages of arbitrary length. Using it, the interlocutors are not required to be online at the same time. All messages are accumulated on the server and downloaded from it on demand after the user successfully passes authorization. Decryption takes place locally using secret keys that are not transmitted anywhere. Mail with PGP is popular, but it is far from perfect. Why? See the article “Alice and Bob in PGP Country”.
Unfortunately, in its pure form, an asymmetric encryption scheme is also not suitable for messengers, since these services are focused on intensive online correspondence in the form of a chain of short messages. They must be displayed in a strictly defined order, and the interlocutor can be offline at any time and disrupt the structure of the dialogue.
Also, encrypting many short messages with one key is a bad idea. In total, hundreds (if not thousands) of them are created per day of correspondence. In many messages, the amount of ciphertext is minimal and predictable (emoticon, sticker). They also have standard headers that simplify cryptanalysis.
The peculiarity of the correspondence in the messengers is that due to the typical metadata in an short time, the attacker can intercept a large amount of predictable ciphertext. Its lion's share will correspond to the well-known open text. If it is encrypted with one key, then a successful attack will compromise all previously written messages, and even those that the interlocutors will write in the future.
To prevent this from happening, messengers provide such properties as direct and reverse secrecy. They imply the inability to read messages sent earlier and written in the future, having only the current encryption key on hand. For this, multilayer encryption is used with the transition from asymmetric to symmetric cryptography and additional keys with different lifetimes.
Diffie, Hellman! Give three!
From open documentation it is known that in Telegram, an authenticated key distribution provides the classic Diffie-Hellman (DH) protocol. It creates a bridge between asymmetric (RSA) and symmetric (AES) encryption, enabling a certain number of interlocutors to conduct encrypted correspondence, transmitting only public keys over an open channel. For this, session keys are generated in it, which are a shared secret or a shared ephemeral key. It is calculated based on the secret key of one interlocutor and the public key of another. Ephemeral keys are authenticated by long-term public keys.
In DH, the transmission channel may not be protected from listening (passive surveillance), but it must be protected from spoofing attacks. If the attacker can substitute traffic (perform an active MITM attack), then the whole scheme goes to hell.
Therefore, for its Signal messenger, Open Whisper Systems uses the Diffie-Hellman triple conversion method X3DH with Curve25519 (Bernstein elliptic curve for fast DH) or X448. Other cryptographic primitives in X3DH use HMAC-SHA-256 and AES-256.
Extended Triple Diffie - Hellman protocol establishes a shared secret key between two parties that mutually authenticate each other based on public keys. Additionally, the keys are verified immediately after setting up the session and before starting the transmission of messages. This minimizes the risk of MITM attacks, making them very complex.
X3DH uses four types of keys, three of which are constantly changing:
- IK (identity keys). Secret keys that are created once and serve as the basis for the formation of all the others;
- EK (ephemeral key). The ephemeral key, which is needed to verify the identity of the interlocutor (without divulging the true);
- SPk (signed public key, signed proof of knowledge) - in fact, this is an ephemeral key signed by a secret. Usually in instant messengers it changes with a frequency from one day to a week. Sometimes, instead of the lifetime of SPk, the number of messages is set, after which it changes;
- OPK (one-time public key) - a one-time ephemeral key. It is created by the sender before setting up a communication session and is deleted immediately after a successful “handshake” (handshake).
Changing auxiliary keys in X3DH occurs according to the Double Ratchet algorithm. He replaced the OTR and introduced the concept of a chain, or pool, of keys. In case the interlocutor is offline, the creation of an OPK pool is provided. Several one-time ephemeral keys are uploaded to the server in advance and are consumed as you communicate. This allows the server to receive encrypted messages, authenticating their sender with a new key pair, even when the recipient is offline. If the OPK pool is exhausted, then the server uses a spare EK.
The name “double ratchet” is a reference to the device of the Enigma cryptographic machine with gears, which excluded the reverse movement and reuse of the previous values. The digital analogy is that DR is used to generate new ephemeral keys that encrypt the next message (or a small portion of messages). At the same time, the ephemeral keys are guaranteed to differ, do not repeat the previous ones and cannot be predicted for a reasonable attack time.
X3DH is based on the TextSecure protocol, which was later renamed Signal. In a pure or slightly modified form, the Signal protocol is used in the eponymous messenger, as well as in WhatsApp, Viber, and others. Developers can give the protocol their own names, but in essence it is the same X3DH with a varying set of hash functions, PRNGs and other cryptographic primitives.
Group Chat Problem
The organization of group chats in instant messengers is discussed in detail in the recent article “More is Less: On the End-to-End Security of Group Chats in Signal, WhatsApp, and Threema” (PDF). I will give the main conclusions from it.
Our systematic analysis revealed that the integrity of communications (represented by the integrity of all messages) and group membership (determined by the ability of group members to manage them) do not have end-to-end protection. In addition, we showed that reverse secrecy (a key security feature) is not preserved when using the Signal protocol for group chats.
Explanation: The cornerstone of end-to-end encryption is authenticated key distribution using the classic or enhanced DH protocol. It works only for two interlocutors, forming a common secret. It is expected that in instant messengers DH is not used in group chats, and the messaging structure in them is devoid of basic cryptographic properties.
Encryption in group chats. A - sender, B - receiver, G - user group
The authors show what manipulations a server controlled by an attacker can perform in group chats due to the lack of E2EE in them. They conducted their research on the example of Signal and WhatsApp, but it is unlikely that other messengers can expect this problem to have some elegant solution.
Oddities Telegram
With Telegram, everything is covered in a veil of secrecy. There is only partial information about the MTProto 2.0 protocol. His external audit was not performed, and the open source Telegram model is used in a very distorted form and exclusively for marketing purposes. Below I will explain why I think so.
Judging by the official description, all undelivered messages are temporarily (we hope) stored on Telegram servers, which are often scattered around the world and combined into a virtual cloud. They are synchronized with each other in order to organize and deliver messages to one or several (in the case of group chat) interlocutors in a certain order as soon as they appear on the network. Therefore, encryption is divided into two stages: in the client-server and server-server sections. This is a common scheme, but the strange thing about it is that direct client connections are never used at all.
In Telegram, traffic is transmitted through the servers even when you open a secret chat, for which it would be more logical to make a P2P connection. The conclusion is that without constant use of Telegram servers, communication in this messenger does not work at all. Other messengers can use their servers only at the initial stage - to compare the current IP addresses of the interlocutors and organize a direct connection between them. Telegram doesn’t know how, and it’s damn similar to MITM by design.
For some reason, all arguments about the strength of MTProto 2.0 revolve around the fact that the DH algorithm reliably protects against interception. This is not true. The Diffie-Hellman algorithm is just vulnerable to a MITM attack. Moreover, in the case of Telegram, it is probably further weakened at the PRNG level.
The problem is that the Telegram client application is guided by a very slurred entropy estimate. Instead of locally generating pseudo-random numbers and filtering out quality primes, the client requests them from the server. What kind of PRSP is used on the server, how successful primes it generates, and whether there are any mechanisms on the server to selectively send primes with certain properties to individual clients are unanswered questions. The client application only checks the sent random number, and it’s simplified, because for a thorough prime numbers test in a reasonable time the smartphone will not have enough computing resources.
Another common argument for Telegram security is open source. However, they do not have the source code for the server side, and the client code is usually not relevant. Telegram repositories are updated with a long delay (unless the truncated web version is more or less lively), and they always contain only old versions. There is not even an opportunity to check whether the source code really compiles what is now distributed as a finished distribution.
Therefore, talking about the messenger audit is practically pointless. While specialists dig around the old code for several months, a dozen new versions of Telegram will be released, where huge pieces of code will be rewritten. To make the entire encryption system vulnerable, it is enough to replace one byte - for example, one conditional branch.
The hackathons that Durov is happy with will not replace the audit, since they prove nothing. Their tasks create an artificial situation in which the attacking side has only one encrypted message. In real life there are no such restrictions and there are many other vectors for attacking the messenger.
A Thousand and One Vulnerabilities
Signal - one of the few instant messengers whose protocol passed an external audit (PDF). The report on its results is very voluminous, so I will quote the main conclusions in my translation.
Our analysis shows that [protocol] Signal satisfies standard cryptographic assumptions and security features. We did not find any serious flaws in its design, which is very encouraging. With actual use of Signal, uncertainties remain. Therefore, it is impossible to say whether [Signal] Signal always achieves its stated goals.
You need to be aware that the analysis of the messaging protocol is an important stage of the audit, but by no means the only component of security. Any messenger works in a real and very vulnerable environment. Usually it runs on a not the latest version of Android, in parallel with a hundred left-handed applications (some of which probably abuse permissions or even contain Trojan bookmarks), and the account itself is tied to a mobile phone number.
A huge gap lies in the fact that confirmation codes come in SMS. They can be intercepted through a known vulnerability in the SS7 cellular communication protocol. So the attacker will gain access to the entire correspondence, without knowing the encryption keys and not even trying to crack the Signal / Proteus / MTProto / other security protocol. The messenger server itself will change the key and helpfully decrypt the last correspondence (at least, undelivered messages). Even your sticker packs will recover. The main thing is convenience, right?
Another gaping hole in the security model is push notifications. Without them, you won’t know that you received a message until you manually launch the messenger. With them, you turn the server of push notifications into a legalized “man in the middle”. For example, for notifications to work in iMessage, it sends encryption keys to Apple servers. They already perform user authentication and (at least) decryption of message headers. Restore your Apple account on another device, and you’ll get everything as it was - up to correspondence and passwords from Wi-Fi. Almost the same situation with the servers Google and Microsoft. Or do you still believe in end-to-end encryption with reference to the mobile number and the main account on your smartphone?
The problem of unsafe key management and a large attack surface concerns all instant messengers in general. WhatsApp, Viber and many others allow you to create copies of correspondence (including cloud) and do not encrypt metadata (and sometimes the fact of a conversation is more important than its content). Signal is doing a little better, but I do not consider it an ideal messenger for a number of reasons:
- Firstly, Signal also uses the Google push notification service. Therefore, on a smartphone without Google services (for example, all Chinese models for the domestic market without GApps), it simply does not work.
- Secondly, Signal uses a closed RedPhone server for voice communication.
- Thirdly, Signal (like many other instant messengers) allows you to open a parallel session on another device, simply by scanning a QR code.
- Fourth, they told HITBSecConf2017 (PDF) about a number of Signal's conceptual issues and demonstrated a successful attack on it.
As you can see, third-party and especially proprietary messengers are difficult to trust, even if they were recommended by Snowden, Assange and EFF. Therefore, some organize communication through their messenger - with open source and plug-ins. The OTR plugin is suitable for simple correspondence, but it does not support group chats. There are related protocols mpOTR and GOTR, in which this function is added.
One way or another, for collective communication it is more convenient to use the open XMPP protocol (Extensible Messaging and Presence Protocol), which was formerly called Jabber. XMPP translates as “Extensible Messaging and Presence Protocol,” a very long name. Openness means full accessibility of source codes. You can raise your XMPP server, not depend on anyone and pay nothing for it. There is also a lot of ready-made servers and clients for every taste - for example, desktop Pidgin and Xabber for Android.
Extensibility implies the ability to transfer not only text, but also data of a different type, as well as the addition of various functions and encryption schemes. For example, via XMPP it is easy to transfer voice messages, videos and files, if desired, encrypted them using TLS or PGP. Not so long ago, based on XMPP, the OMEMO extension protocol was created, which uses the same DR from Open Whisper Systems as in Signal and WhatsApp, but without the other drawbacks of the latter.
conclusions
Modern messengers claim end-to-end encryption support, but it often turns out that it is implemented with weirdness. In addition, there are many other holes in their code that were left accidentally or intentionally. The latter is much more likely when you consider how much money and labor of professionals was invested in their development. I try to strike a balance between comfort and the usual enjoyment of paranoia. I use different messengers (which are more convenient for my interlocutors), but I never conduct really private conversations through them. There are many open source alternatives for this.
Source
Original message
Сквозное шифрование, или end-to-end encryption (E2EE), считается панацеей от настойчивых попыток хакеров и силовых ведомств ознакомиться с онлайновой перепиской. Смысл E2EE часто сводится к тому, что ключи хранятся только на устройствах собеседников и не попадают на сервер… но это не совсем так. Давай посмотрим, как в действительности обстоят дела с E2EE, на примере популярных мессенджеров.
Шифрование в мессенджерах
Написать эту статью меня подтолкнуло исследование Obstacles to the Adoption of Secure Communication Tools (PDF). Как выяснили его авторы, «подавляющее большинство участников опроса не понимают основную концепцию сквозного шифрования». Проще говоря, люди обычно выбирают мессенджер сердцем, а не мозгом.
Начнем с того, что E2EE имеет свои особенности в каждом мессенджере. В Signal оно почти образцовое. В WhatsApp формально такое же, как в Signal, за исключением одного очень важного момента: смена основного ключа абонента WhatsApp не блокирует отправку ему сообщений. Максимум можно включить бесполезное уведомление (которое отключено в дефолтных настройках). В Viber сквозное шифрование неактивно по умолчанию, да и появилось только в шестой версии. В Telegram E2EE также используется только в секретных чатах, причем реализованы они довольно странно.
Конфликт Роскомнадзора с Telegram вообще создал отличную рекламу последнему. Рядовые пользователи теперь считают творение Дурова настоящей занозой в спине спецслужб (или чуть пониже нее), которые ничего не могут сделать с пуленепробиваемым инновационным сервисом. Поклонники Telegram сравнивают его с Signal и утверждают о превосходстве первого.
Однако в криптографии не бывает чудес, и особенно — в прикладной. Многие математически красивые идеи оказываются безнадежно испорчены реализацией, когда удобство и подконтрольность ставят выше безопасности и приватности (а так происходит практически всегда).
Исходно в мессенджерах применялся протокол OTR (Off-the-Record). Он использует симметричное шифрование AES в режиме CTR, протокол обмена ключами DH и хеш-функцию SHA-1. Схема AES-CTR обеспечивает так называемое «спорное» (в хорошем смысле) шифрование и возможность отрицания авторства текста, если его перехватят. Всегда можно сослаться на то, что перехвативший трафик сам изменил шифротекст так, чтобы он соответствовал другому варианту расшифровки той же длины. Например, вместо «сходи за хлебом» получилось «отрави королеву» — технически это возможно, и такое свойство специально заложено в алгоритм.
Протокол OTR выполняет аутентификацию собеседников и шифрует переписку между ними. Он безопасен до тех пор, пока участники разговора регулярно проверяют отпечатки открытых ключей друг друга и противостоят атакам по другим векторам (включая социальный инжиниринг).
Главный недостаток OTR заключается в том, что после отправки нового ключа требуется дождаться подтверждения от собеседника. Если он офлайн, то связь будет временно невозможна. Одним из выходов стал алгоритм Double Ratchet (DR), разработанный пять лет назад Тревором Перрином и Мокси Марлинспайком в Open Whisper Systems. Сегодня DR используется в Signal, WhatsApp, Viber и многих других мессенджерах, поддерживающих сквозное шифрование по умолчанию или как отдельную опцию (секретные чаты).
Упрощенная схема алгоритма Double Ratchet (источник: signal.org). Алиса и Боб начинают сессию, обмениваясь публичными ключами
Сквозное шифрование
Схема E2EE использует комбинацию из криптографических систем с открытым и закрытым ключом. Она очевидна в общих чертах и довольно сложна на уровне деталей. В ней используется масса взаимосвязанных ключей, часть из которых обязательно попадает на сервер и, более того, обязательно загружается на него до начала переписки, чтобы ее можно было начать в произвольный момент. Давай рассмотрим ее подробнее.
Начало схемы ты наверняка знаешь, поскольку оно стандартно для всех систем асимметричного шифрования, — генерируется пара ключей. Это необходимо потому, что криптосистемы с одним ключом (вроде AES) использовать в переписке в чистом виде слишком трудно. С ними пришлось бы как-то организовывать защищенный канал для передачи ключа (например, встречаться лично), а потом делать это снова при каждой его смене.
Тут же все как в привычном PGP: есть два собеседника (Алиса и Боб), каждый из которых генерирует свою пару ключей. Затем они обмениваются публичными ключами, сохраняя в тайне парные им секретные. Публичные ключи передаются по открытому каналу (на то они и публичные, пусть перехватывают на здоровье) и служат для двух целей: они позволяют зашифровать сообщение и проверить его подпись. Соответственно, секретные ключи используются для расшифровки и формирования подписи.
Термин «сообщение» используется здесь в широком смысле. Сообщением может быть текст, медиафайл или служебные метаданные, которыми мессенджер обменивается с сервером. Часть этих данных содержит временные метки, состояние клиентского приложения и новые ключи.
Такая криптосистема кое-как работает в электронной почте, поскольку это сервис для доставки отдельных зашифрованных сообщений произвольной длины. Пользуясь им, собеседники не обязаны одновременно быть онлайн. Все сообщения накапливаются на сервере и скачиваются с него по требованию после того, как пользователь успешно пройдет авторизацию. Расшифровка происходит локально при помощи секретных ключей, которые никуда не передаются. Почта с PGP популярна, но работает далеко не идеально. Почему? См. статью «Алиса и Боб в стране PGP».
К сожалению, в чистом виде схема асимметричного шифрования также не годится для мессенджеров, поскольку эти сервисы ориентированы на интенсивную онлайновую переписку в виде цепочки коротких сообщений. Они должны отображаться в строго определенном порядке, а собеседник может в любое время оказаться офлайн и нарушить структуру диалога.
К тому же шифровать множество коротких сообщений одним ключом — плохая идея. Всего за день переписки их создаются сотни (если не тысячи). Во многих сообщениях количество шифротекста минимальное и предсказуемое (смайлик, стикер). Также у них есть стандартные заголовки, которые упрощают криптоанализ.
Особенность переписки в мессенджерах в том, что из-за типовых метаданных за короткое время атакующий может перехватить большой объем предсказуемого шифротекста. Его львиная доля будет соответствовать известному открытому тексту. Если она будет шифроваться одним ключом, то при успешной атаке окажутся скомпрометированными все ранее написанные сообщения, и даже те, которые собеседники напишут в будущем.
Чтобы этого не происходило, в мессенджерах предусмотрены такие свойства, как прямая и обратная секретность. Они подразумевают невозможность прочитать отправленные ранее и написанные в будущем сообщения, имея на руках только текущий ключ шифрования. Для этого используется многослойное шифрование с переходом от асимметричной к симметричной криптографии и дополнительные ключи с разным временем жизни.
Диффи, Хеллман! Дайте три!
Из открытой документации известно, что в Telegram аутентифицированное распределение ключей обеспечивает классический протокол Диффи — Хеллмана (DH). Он создает мост между асимметричным (RSA) и симметричным (AES) шифрованием, давая возможность энному количеству собеседников вести зашифрованную переписку, передав только публичные ключи по открытому каналу. Для этого в нем генерируются сессионные ключи, представляющие собой общий секрет или общий эфемерный ключ. Он вычисляется на основе секретного ключа одного собеседника и публичного ключа другого. Эфемерные ключи аутентифицируются долговременными открытыми ключами.
В DH канал передачи может быть не защищен от прослушивания (пассивного наблюдения), но обязан иметь защиту от атаки подмены. Если атакующая сторона может подменить трафик (выполнить активную атаку MITM), то вся схема летит к черту.
Поэтому для своего мессенджера Signal компания Open Whisper Systems использует метод тройного преобразования Диффи — Хеллмана X3DH c Curve25519 (эллиптическая кривая Бернстайна для быстрого DH) или X448. В качестве других криптографических примитивов в X3DH используется HMAC-SHA-256 и AES-256.
Протокол Extended Triple Diffie — Hellman устанавливает общий секретный ключ между двумя сторонами, которые взаимно аутентифицируют друг друга на основе открытых ключей. Дополнительно ключи сверяются сразу после установки сессии и перед началом передачи сообщений. Это сводит к минимуму риск MITM-атак, делая их очень сложными.
В X3DH используются четыре типа ключей, три из которых постоянно меняются:
Смена вспомогательных ключей в X3DH происходит по алгоритму Double Ratchet. Он пришел на смену OTR и ввел понятие цепочки, или пула, ключей. На случай, если собеседник будет офлайн, предусмотрено создание пула OPK. Несколько разовых эфемерных ключей заранее загружаются на сервер и расходуются по мере общения. Это позволяет серверу принимать зашифрованные сообщения, аутентифицируя их отправителя по новой паре ключей, даже когда получатель не в сети. Если пул OPK исчерпан, то сервер использует запасной EK.
Название «двойной храповик» — отсылка к устройству шифровальной машины Enigma с зубчатыми колесиками, которые исключали обратное движение и повторное использование прежних значений. Цифровая аналогия в том, что DR используется для генерирования новых эфемерных ключей, которыми шифруется следующее сообщение (или небольшая порция сообщений). При этом эфемерные ключи гарантированно отличаются, не повторяют предыдущие и не могут быть предсказаны за разумное время атаки.
На X3DH основан протокол TextSecure, который позже был переименован в Signal. В чистом или слегка модифицированном виде протокол Signal используется в одноименном мессенджере, а также в WhatsApp, Viber и других. Разработчики могут давать протоколам собственные названия, но по сути это все тот же X3DH с варьирующимся набором хеш-функций, ГПСЧ и иных криптографических примитивов.
Проблема групповых чатов
Организация групповых чатов в мессенджерах подробно разобрана в свежей статье «More is Less: On the End-to-End Security of Group Chats in Signal, WhatsApp, and Threema» (PDF). Приведу основные выводы из нее.
Наш систематический анализ выявил, что целостность коммуникаций (представленная целостностью всех сообщений) и групповая принадлежность (определяемая возможностью членов группы управлять ими) не имеют end-to-end-защиты. Кроме того, мы показали, что обратная секретность (ключевое свойство безопасности) не сохраняется при использовании протокола Signal для групповых чатов.
Пояснение: краеугольный камень сквозного шифрования — аутентифицированное распределение ключей по классическому или усиленному протоколу DH. Оно работает только для двух собеседников, формирующих общий секрет. Ожидаемо, что в мессенджерах DH не используется в групповых чатах, а структура обмена сообщениями в них лишена основных криптографических свойств.
Шифрование в групповых чатах. A — отправитель, B — получатель, G — группа пользователей
Авторы показывают, какие манипуляции может выполнять контролируемый злоумышленником сервер в групповых чатах из-за отсутствия в них E2EE. Свои исследования они проводили на примере Signal и WhatsApp, но вряд ли стоит ожидать, что у других мессенджеров эта проблема имеет какое-то изящное решение.
Странности Telegram
С Telegram все покрыто завесой тайны. О протоколе MTProto 2.0 есть только частичные сведения. Его внешний аудит не выполнялся, а опенсорсная модель Telegram используется в сильно искаженном виде и исключительно с маркетинговыми целями. Ниже я поясню, почему так считаю.
Судя по официальному описанию, все недоставленные сообщения временно (мы надеемся) хранятся на серверах Telegram, которые часто разбросаны по миру и объединены в виртуальное облако. Они синхронизируются между собой, чтобы упорядочить и доставить сообщения одному или нескольким (в случае группового чата) собеседникам в определенном порядке, как только они появятся в сети. Поэтому шифрование делится на два этапа: на участках клиент — сервер и сервер — сервер. Это обычная схема, но в ней странно то, что прямое соединение клиентов не используется вообще никогда.
В Telegram трафик передается через серверы даже при открытии секретного чата, для которого логичнее было бы сделать P2P-соединение. Напрашивается вывод, что без постоянного использования серверов Telegram связь в этом мессенджере вообще не работает. Другие мессенджеры могут использовать свои серверы только на начальном этапе — для сопоставления текущих IP-адресов собеседников и организации между ними прямого соединения. Telegram так не умеет, и это чертовски похоже на MITM by design.
Почему-то все рассуждения о стойкости MTProto 2.0 крутятся вокруг того, что алгоритм DH надежно защищает от перехвата. Это не так. Алгоритм Диффи — Хеллмана как раз уязвим для атаки MITM. Более того, в случае Telegram он, вероятно, дополнительно ослаблен на уровне ГПСЧ.
Проблема в том, что клиентское приложение Telegram руководствуется очень невнятной оценкой энтропии. Вместо того чтобы локально генерировать псевдослучайные числа и отсеивать качественные простые, клиент запрашивает их с сервера. Что за ГПСЧ используется на сервере, насколько удачные простые числа он генерирует и нет ли на сервере механизмов избирательной отправки простых чисел с определенными свойствами отдельным клиентам — вопросы без ответа. Клиентское приложение лишь выполняет проверку присланного случайного числа, причем упрощенную, поскольку на тщательный тест prime numbers за разумное время у смартфона банально не хватит вычислительных ресурсов.
Другой частый аргумент в пользу безопасности Telegram — открытые исходники. Однако в них нет исходного кода серверной части, а код клиентской обычно неактуален. Репозитории Telegram обновляются с большой задержкой (разве что урезанная веб-версия более-менее живая), и в них всегда лежат только старые версии. Нет даже возможности проверить, действительно ли из исходников компилируется то, что сейчас раздается как готовый дистрибутив.
Поэтому говорить про аудит мессенджера фактически бессмысленно. Пока специалисты несколько месяцев копаются в старом коде, выйдет десяток новых версий Telegram, где будут переписаны огромные куски кода. Чтобы сделать уязвимой всю систему шифрования, достаточно замены одного байта — например, одного условного перехода.
Хакатоны, которые устраивает Дуров, не заменят аудит, поскольку ничего не доказывают. В их заданиях создается искусственная ситуация, в которой у атакующей стороны есть только одно зашифрованное сообщение. В реальной жизни таких ограничений нет и для атаки на мессенджер есть множество других векторов.
Тысяча и одна уязвимость
Signal — один из немногих мессенджеров, чей протокол проходил внешний аудит (PDF). Отчет о его результатах очень объемный, поэтому процитирую главные выводы в своем переводе.
Наш анализ показывает, что [протокол] Signal удовлетворяет стандартным криптографическим предположениям и свойствам безопасности. Мы не обнаружили серьезных недостатков в его дизайне, что очень обнадеживает. При реальном использовании Signal остаются неопределенности. Поэтому невозможно сказать, всегда ли [приложение] Signal достигает заявленных целей.
Нужно осознавать, что анализ протокола передачи сообщений — важный этап аудита, но далеко не единственная составляющая безопасности. Любой мессенджер работает в реальной и очень уязвимой среде. Обычно он запускается на не самой свежей версии Android, параллельно с сотней левых приложений (часть из которых наверняка злоупотребляют разрешениями или даже содержат троянские закладки), а сам аккаунт привязан к номеру мобильного телефона.
Огромная брешь заключается в том, что коды подтверждения приходят в SMS. Их можно перехватить через известную уязвимость в протоколе сотовой связи SS7. Так атакующий получит доступ ко всей переписке, не зная ключей шифрования и даже не пытаясь взломать Signal/Proteus/MTProto/другойсекьюрныйпротокол. Сервер мессенджера сам сменит ключ и услужливо дешифрует последнюю переписку (как минимум, недоставленные сообщения). Даже твои стикерпаки восстановит. Главное же — удобство, верно?
Еще одна зияющая дыра в модели безопасности — push-уведомления. Без них ты не узнаешь, что тебе пришло сообщение, пока вручную не запустишь мессенджер. С ними ты превращаешь сервер push-уведомлений в легализованного «человека посередине». Например, чтобы в iMessage работали уведомления, он отправляет ключи шифрования на серверы Apple. Уже они выполняют аутентификацию пользователей и (как минимум) дешифровку заголовков сообщений. Восстанови учетку Apple на другом устройстве, и ты получишь все как было — вплоть до переписки и паролей от Wi-Fi. Почти такая же ситуация с серверами Google и Microsoft. Или ты еще веришь в сквозное шифрование с привязкой к номеру мобильного и основному аккаунту на смартфоне?
Проблема небезопасного управления ключами и большой поверхности атаки касается вообще всех мессенджеров. WhatsApp, Viber и многие другие позволяют создавать копии переписки (в том числе облачные) и не шифруют метаданные (а иногда сам факт разговора важнее его содержания). У Signal дела обстоят чуть лучше, но и его я не считаю идеальным мессенджером по целому ряду причин:
Как видишь, сторонним и тем более проприетарным мессенджерам доверять сложно, даже если их рекомендовали Сноуден, Ассанж и EFF. Поэтому некоторые организуют общение через свой мессенджер — с опенсорсом и плагинами. Для простой переписки годится плагин OTR, но он не поддерживает групповые чаты. Есть родственные протоколы mpOTR и GOTR, в которых добавлена эта функция.
Так или иначе, для коллективного общения удобнее использовать открытый протокол XMPP (Extensible Messaging and Presence Protocol), который ранее назывался Jabber. XMPP переводится как «расширяемый протокол обмена сообщениями и информацией о присутствии», это очень емкое название. Открытость означает полную доступность исходных кодов. Ты можешь поднять свой сервер XMPP, ни от кого не зависеть и ничего за это не платить. Также есть уйма готовых серверов и клиентов на любой вкус — например, десктопный Pidgin и Xabber для Android.
Расширяемость подразумевает возможность передачи не только текста, но и данных другого типа, а также добавление разных функций и схем шифрования. Например, по XMPP легко передать голосовые сообщения, видео и файлы, при желании зашифровав их средствами TLS или PGP. Не так давно на базе XMPP был создан протокол расширения OMEMO, в котором используется тот же DR от Open Whisper Systems, что и в Signal и WhatsApp, но без прочих недостатков последних.
Выводы
В современных мессенджерах заявлена поддержка сквозного шифрования, но часто оказывается, что она реализована со странностями. К тому же в их коде много других дыр, которые были оставлены случайно либо намеренно. Последнее куда вероятнее, если учесть, сколько денег и труда профессионалов было вложено в их разработку. Я стараюсь соблюдать баланс между комфортом и привычным наслаждением паранойей. Использую разные мессенджеры (какие удобнее моим собеседникам), но никогда не веду через них действительно приватных бесед. Для этого есть множество опенсорсных альтернатив.
Источник
Шифрование в мессенджерах
Написать эту статью меня подтолкнуло исследование Obstacles to the Adoption of Secure Communication Tools (PDF). Как выяснили его авторы, «подавляющее большинство участников опроса не понимают основную концепцию сквозного шифрования». Проще говоря, люди обычно выбирают мессенджер сердцем, а не мозгом.
Начнем с того, что E2EE имеет свои особенности в каждом мессенджере. В Signal оно почти образцовое. В WhatsApp формально такое же, как в Signal, за исключением одного очень важного момента: смена основного ключа абонента WhatsApp не блокирует отправку ему сообщений. Максимум можно включить бесполезное уведомление (которое отключено в дефолтных настройках). В Viber сквозное шифрование неактивно по умолчанию, да и появилось только в шестой версии. В Telegram E2EE также используется только в секретных чатах, причем реализованы они довольно странно.
Конфликт Роскомнадзора с Telegram вообще создал отличную рекламу последнему. Рядовые пользователи теперь считают творение Дурова настоящей занозой в спине спецслужб (или чуть пониже нее), которые ничего не могут сделать с пуленепробиваемым инновационным сервисом. Поклонники Telegram сравнивают его с Signal и утверждают о превосходстве первого.
Однако в криптографии не бывает чудес, и особенно — в прикладной. Многие математически красивые идеи оказываются безнадежно испорчены реализацией, когда удобство и подконтрольность ставят выше безопасности и приватности (а так происходит практически всегда).
Исходно в мессенджерах применялся протокол OTR (Off-the-Record). Он использует симметричное шифрование AES в режиме CTR, протокол обмена ключами DH и хеш-функцию SHA-1. Схема AES-CTR обеспечивает так называемое «спорное» (в хорошем смысле) шифрование и возможность отрицания авторства текста, если его перехватят. Всегда можно сослаться на то, что перехвативший трафик сам изменил шифротекст так, чтобы он соответствовал другому варианту расшифровки той же длины. Например, вместо «сходи за хлебом» получилось «отрави королеву» — технически это возможно, и такое свойство специально заложено в алгоритм.
Протокол OTR выполняет аутентификацию собеседников и шифрует переписку между ними. Он безопасен до тех пор, пока участники разговора регулярно проверяют отпечатки открытых ключей друг друга и противостоят атакам по другим векторам (включая социальный инжиниринг).
Главный недостаток OTR заключается в том, что после отправки нового ключа требуется дождаться подтверждения от собеседника. Если он офлайн, то связь будет временно невозможна. Одним из выходов стал алгоритм Double Ratchet (DR), разработанный пять лет назад Тревором Перрином и Мокси Марлинспайком в Open Whisper Systems. Сегодня DR используется в Signal, WhatsApp, Viber и многих других мессенджерах, поддерживающих сквозное шифрование по умолчанию или как отдельную опцию (секретные чаты).
Упрощенная схема алгоритма Double Ratchet (источник: signal.org). Алиса и Боб начинают сессию, обмениваясь публичными ключами
Сквозное шифрование
Схема E2EE использует комбинацию из криптографических систем с открытым и закрытым ключом. Она очевидна в общих чертах и довольно сложна на уровне деталей. В ней используется масса взаимосвязанных ключей, часть из которых обязательно попадает на сервер и, более того, обязательно загружается на него до начала переписки, чтобы ее можно было начать в произвольный момент. Давай рассмотрим ее подробнее.
Начало схемы ты наверняка знаешь, поскольку оно стандартно для всех систем асимметричного шифрования, — генерируется пара ключей. Это необходимо потому, что криптосистемы с одним ключом (вроде AES) использовать в переписке в чистом виде слишком трудно. С ними пришлось бы как-то организовывать защищенный канал для передачи ключа (например, встречаться лично), а потом делать это снова при каждой его смене.
Тут же все как в привычном PGP: есть два собеседника (Алиса и Боб), каждый из которых генерирует свою пару ключей. Затем они обмениваются публичными ключами, сохраняя в тайне парные им секретные. Публичные ключи передаются по открытому каналу (на то они и публичные, пусть перехватывают на здоровье) и служат для двух целей: они позволяют зашифровать сообщение и проверить его подпись. Соответственно, секретные ключи используются для расшифровки и формирования подписи.
Термин «сообщение» используется здесь в широком смысле. Сообщением может быть текст, медиафайл или служебные метаданные, которыми мессенджер обменивается с сервером. Часть этих данных содержит временные метки, состояние клиентского приложения и новые ключи.
Такая криптосистема кое-как работает в электронной почте, поскольку это сервис для доставки отдельных зашифрованных сообщений произвольной длины. Пользуясь им, собеседники не обязаны одновременно быть онлайн. Все сообщения накапливаются на сервере и скачиваются с него по требованию после того, как пользователь успешно пройдет авторизацию. Расшифровка происходит локально при помощи секретных ключей, которые никуда не передаются. Почта с PGP популярна, но работает далеко не идеально. Почему? См. статью «Алиса и Боб в стране PGP».
К сожалению, в чистом виде схема асимметричного шифрования также не годится для мессенджеров, поскольку эти сервисы ориентированы на интенсивную онлайновую переписку в виде цепочки коротких сообщений. Они должны отображаться в строго определенном порядке, а собеседник может в любое время оказаться офлайн и нарушить структуру диалога.
К тому же шифровать множество коротких сообщений одним ключом — плохая идея. Всего за день переписки их создаются сотни (если не тысячи). Во многих сообщениях количество шифротекста минимальное и предсказуемое (смайлик, стикер). Также у них есть стандартные заголовки, которые упрощают криптоанализ.
Особенность переписки в мессенджерах в том, что из-за типовых метаданных за короткое время атакующий может перехватить большой объем предсказуемого шифротекста. Его львиная доля будет соответствовать известному открытому тексту. Если она будет шифроваться одним ключом, то при успешной атаке окажутся скомпрометированными все ранее написанные сообщения, и даже те, которые собеседники напишут в будущем.
Чтобы этого не происходило, в мессенджерах предусмотрены такие свойства, как прямая и обратная секретность. Они подразумевают невозможность прочитать отправленные ранее и написанные в будущем сообщения, имея на руках только текущий ключ шифрования. Для этого используется многослойное шифрование с переходом от асимметричной к симметричной криптографии и дополнительные ключи с разным временем жизни.
Диффи, Хеллман! Дайте три!
Из открытой документации известно, что в Telegram аутентифицированное распределение ключей обеспечивает классический протокол Диффи — Хеллмана (DH). Он создает мост между асимметричным (RSA) и симметричным (AES) шифрованием, давая возможность энному количеству собеседников вести зашифрованную переписку, передав только публичные ключи по открытому каналу. Для этого в нем генерируются сессионные ключи, представляющие собой общий секрет или общий эфемерный ключ. Он вычисляется на основе секретного ключа одного собеседника и публичного ключа другого. Эфемерные ключи аутентифицируются долговременными открытыми ключами.
В DH канал передачи может быть не защищен от прослушивания (пассивного наблюдения), но обязан иметь защиту от атаки подмены. Если атакующая сторона может подменить трафик (выполнить активную атаку MITM), то вся схема летит к черту.
Поэтому для своего мессенджера Signal компания Open Whisper Systems использует метод тройного преобразования Диффи — Хеллмана X3DH c Curve25519 (эллиптическая кривая Бернстайна для быстрого DH) или X448. В качестве других криптографических примитивов в X3DH используется HMAC-SHA-256 и AES-256.
Протокол Extended Triple Diffie — Hellman устанавливает общий секретный ключ между двумя сторонами, которые взаимно аутентифицируют друг друга на основе открытых ключей. Дополнительно ключи сверяются сразу после установки сессии и перед началом передачи сообщений. Это сводит к минимуму риск MITM-атак, делая их очень сложными.
В X3DH используются четыре типа ключей, три из которых постоянно меняются:
- IK (identity keys). Секретные ключи, которые создаются один раз и служат основой для формирования всех остальных;
- EK (ephemeral key). Эфемерный ключ, который нужен для проверки личности собеседника (без разглашения истинной);
- SPk (signed public key, signed proof of knowledge) — по сути, это эфемерный ключ, подписанный секретным. Обычно в мессенджерах он меняется с частотой от одного дня до недели. Иногда вместо времени жизни SPk задают число сообщений, после которого он меняется;
- OPK (one-time public key) — одноразовый эфемерный ключ. Он создается отправителем перед установкой сеанса связи и удаляется сразу после успешного «рукопожатия» (handshake).
Смена вспомогательных ключей в X3DH происходит по алгоритму Double Ratchet. Он пришел на смену OTR и ввел понятие цепочки, или пула, ключей. На случай, если собеседник будет офлайн, предусмотрено создание пула OPK. Несколько разовых эфемерных ключей заранее загружаются на сервер и расходуются по мере общения. Это позволяет серверу принимать зашифрованные сообщения, аутентифицируя их отправителя по новой паре ключей, даже когда получатель не в сети. Если пул OPK исчерпан, то сервер использует запасной EK.
Название «двойной храповик» — отсылка к устройству шифровальной машины Enigma с зубчатыми колесиками, которые исключали обратное движение и повторное использование прежних значений. Цифровая аналогия в том, что DR используется для генерирования новых эфемерных ключей, которыми шифруется следующее сообщение (или небольшая порция сообщений). При этом эфемерные ключи гарантированно отличаются, не повторяют предыдущие и не могут быть предсказаны за разумное время атаки.
На X3DH основан протокол TextSecure, который позже был переименован в Signal. В чистом или слегка модифицированном виде протокол Signal используется в одноименном мессенджере, а также в WhatsApp, Viber и других. Разработчики могут давать протоколам собственные названия, но по сути это все тот же X3DH с варьирующимся набором хеш-функций, ГПСЧ и иных криптографических примитивов.
Проблема групповых чатов
Организация групповых чатов в мессенджерах подробно разобрана в свежей статье «More is Less: On the End-to-End Security of Group Chats in Signal, WhatsApp, and Threema» (PDF). Приведу основные выводы из нее.
Наш систематический анализ выявил, что целостность коммуникаций (представленная целостностью всех сообщений) и групповая принадлежность (определяемая возможностью членов группы управлять ими) не имеют end-to-end-защиты. Кроме того, мы показали, что обратная секретность (ключевое свойство безопасности) не сохраняется при использовании протокола Signal для групповых чатов.
Пояснение: краеугольный камень сквозного шифрования — аутентифицированное распределение ключей по классическому или усиленному протоколу DH. Оно работает только для двух собеседников, формирующих общий секрет. Ожидаемо, что в мессенджерах DH не используется в групповых чатах, а структура обмена сообщениями в них лишена основных криптографических свойств.
Шифрование в групповых чатах. A — отправитель, B — получатель, G — группа пользователей
Авторы показывают, какие манипуляции может выполнять контролируемый злоумышленником сервер в групповых чатах из-за отсутствия в них E2EE. Свои исследования они проводили на примере Signal и WhatsApp, но вряд ли стоит ожидать, что у других мессенджеров эта проблема имеет какое-то изящное решение.
Странности Telegram
С Telegram все покрыто завесой тайны. О протоколе MTProto 2.0 есть только частичные сведения. Его внешний аудит не выполнялся, а опенсорсная модель Telegram используется в сильно искаженном виде и исключительно с маркетинговыми целями. Ниже я поясню, почему так считаю.
Судя по официальному описанию, все недоставленные сообщения временно (мы надеемся) хранятся на серверах Telegram, которые часто разбросаны по миру и объединены в виртуальное облако. Они синхронизируются между собой, чтобы упорядочить и доставить сообщения одному или нескольким (в случае группового чата) собеседникам в определенном порядке, как только они появятся в сети. Поэтому шифрование делится на два этапа: на участках клиент — сервер и сервер — сервер. Это обычная схема, но в ней странно то, что прямое соединение клиентов не используется вообще никогда.
В Telegram трафик передается через серверы даже при открытии секретного чата, для которого логичнее было бы сделать P2P-соединение. Напрашивается вывод, что без постоянного использования серверов Telegram связь в этом мессенджере вообще не работает. Другие мессенджеры могут использовать свои серверы только на начальном этапе — для сопоставления текущих IP-адресов собеседников и организации между ними прямого соединения. Telegram так не умеет, и это чертовски похоже на MITM by design.
Почему-то все рассуждения о стойкости MTProto 2.0 крутятся вокруг того, что алгоритм DH надежно защищает от перехвата. Это не так. Алгоритм Диффи — Хеллмана как раз уязвим для атаки MITM. Более того, в случае Telegram он, вероятно, дополнительно ослаблен на уровне ГПСЧ.
Проблема в том, что клиентское приложение Telegram руководствуется очень невнятной оценкой энтропии. Вместо того чтобы локально генерировать псевдослучайные числа и отсеивать качественные простые, клиент запрашивает их с сервера. Что за ГПСЧ используется на сервере, насколько удачные простые числа он генерирует и нет ли на сервере механизмов избирательной отправки простых чисел с определенными свойствами отдельным клиентам — вопросы без ответа. Клиентское приложение лишь выполняет проверку присланного случайного числа, причем упрощенную, поскольку на тщательный тест prime numbers за разумное время у смартфона банально не хватит вычислительных ресурсов.
Другой частый аргумент в пользу безопасности Telegram — открытые исходники. Однако в них нет исходного кода серверной части, а код клиентской обычно неактуален. Репозитории Telegram обновляются с большой задержкой (разве что урезанная веб-версия более-менее живая), и в них всегда лежат только старые версии. Нет даже возможности проверить, действительно ли из исходников компилируется то, что сейчас раздается как готовый дистрибутив.
Поэтому говорить про аудит мессенджера фактически бессмысленно. Пока специалисты несколько месяцев копаются в старом коде, выйдет десяток новых версий Telegram, где будут переписаны огромные куски кода. Чтобы сделать уязвимой всю систему шифрования, достаточно замены одного байта — например, одного условного перехода.
Хакатоны, которые устраивает Дуров, не заменят аудит, поскольку ничего не доказывают. В их заданиях создается искусственная ситуация, в которой у атакующей стороны есть только одно зашифрованное сообщение. В реальной жизни таких ограничений нет и для атаки на мессенджер есть множество других векторов.
Тысяча и одна уязвимость
Signal — один из немногих мессенджеров, чей протокол проходил внешний аудит (PDF). Отчет о его результатах очень объемный, поэтому процитирую главные выводы в своем переводе.
Наш анализ показывает, что [протокол] Signal удовлетворяет стандартным криптографическим предположениям и свойствам безопасности. Мы не обнаружили серьезных недостатков в его дизайне, что очень обнадеживает. При реальном использовании Signal остаются неопределенности. Поэтому невозможно сказать, всегда ли [приложение] Signal достигает заявленных целей.
Нужно осознавать, что анализ протокола передачи сообщений — важный этап аудита, но далеко не единственная составляющая безопасности. Любой мессенджер работает в реальной и очень уязвимой среде. Обычно он запускается на не самой свежей версии Android, параллельно с сотней левых приложений (часть из которых наверняка злоупотребляют разрешениями или даже содержат троянские закладки), а сам аккаунт привязан к номеру мобильного телефона.
Огромная брешь заключается в том, что коды подтверждения приходят в SMS. Их можно перехватить через известную уязвимость в протоколе сотовой связи SS7. Так атакующий получит доступ ко всей переписке, не зная ключей шифрования и даже не пытаясь взломать Signal/Proteus/MTProto/другойсекьюрныйпротокол. Сервер мессенджера сам сменит ключ и услужливо дешифрует последнюю переписку (как минимум, недоставленные сообщения). Даже твои стикерпаки восстановит. Главное же — удобство, верно?
Еще одна зияющая дыра в модели безопасности — push-уведомления. Без них ты не узнаешь, что тебе пришло сообщение, пока вручную не запустишь мессенджер. С ними ты превращаешь сервер push-уведомлений в легализованного «человека посередине». Например, чтобы в iMessage работали уведомления, он отправляет ключи шифрования на серверы Apple. Уже они выполняют аутентификацию пользователей и (как минимум) дешифровку заголовков сообщений. Восстанови учетку Apple на другом устройстве, и ты получишь все как было — вплоть до переписки и паролей от Wi-Fi. Почти такая же ситуация с серверами Google и Microsoft. Или ты еще веришь в сквозное шифрование с привязкой к номеру мобильного и основному аккаунту на смартфоне?
Проблема небезопасного управления ключами и большой поверхности атаки касается вообще всех мессенджеров. WhatsApp, Viber и многие другие позволяют создавать копии переписки (в том числе облачные) и не шифруют метаданные (а иногда сам факт разговора важнее его содержания). У Signal дела обстоят чуть лучше, но и его я не считаю идеальным мессенджером по целому ряду причин:
- Во-первых, Signal также использует гугловский сервис push-уведомлений. Поэтому на смартфоне без сервисов Google (например, все китайские модели для внутреннего рынка без GApps) он просто не работает.
- Во-вторых, для голосового общения в Signal используется закрытый сервер RedPhone.
- В-третьих, Signal (как и многие другие мессенджеры) позволяет открыть параллельную сессию на другом устройстве, просто отсканировав QR-код.
- В-четвертых, на HITBSecConf2017 рассказали (PDF) про ряд концептуальных проблем Signal и продемонстрировали успешную атаку на него.
Как видишь, сторонним и тем более проприетарным мессенджерам доверять сложно, даже если их рекомендовали Сноуден, Ассанж и EFF. Поэтому некоторые организуют общение через свой мессенджер — с опенсорсом и плагинами. Для простой переписки годится плагин OTR, но он не поддерживает групповые чаты. Есть родственные протоколы mpOTR и GOTR, в которых добавлена эта функция.
Так или иначе, для коллективного общения удобнее использовать открытый протокол XMPP (Extensible Messaging and Presence Protocol), который ранее назывался Jabber. XMPP переводится как «расширяемый протокол обмена сообщениями и информацией о присутствии», это очень емкое название. Открытость означает полную доступность исходных кодов. Ты можешь поднять свой сервер XMPP, ни от кого не зависеть и ничего за это не платить. Также есть уйма готовых серверов и клиентов на любой вкус — например, десктопный Pidgin и Xabber для Android.
Расширяемость подразумевает возможность передачи не только текста, но и данных другого типа, а также добавление разных функций и схем шифрования. Например, по XMPP легко передать голосовые сообщения, видео и файлы, при желании зашифровав их средствами TLS или PGP. Не так давно на базе XMPP был создан протокол расширения OMEMO, в котором используется тот же DR от Open Whisper Systems, что и в Signal и WhatsApp, но без прочих недостатков последних.
Выводы
В современных мессенджерах заявлена поддержка сквозного шифрования, но часто оказывается, что она реализована со странностями. К тому же в их коде много других дыр, которые были оставлены случайно либо намеренно. Последнее куда вероятнее, если учесть, сколько денег и труда профессионалов было вложено в их разработку. Я стараюсь соблюдать баланс между комфортом и привычным наслаждением паранойей. Использую разные мессенджеры (какие удобнее моим собеседникам), но никогда не веду через них действительно приватных бесед. Для этого есть множество опенсорсных альтернатив.
Источник
