ICO“标王”Telegram的最大卖点安全性恰恰是它的短板！

为什么说Telegram不安全？主要有以下几点：

Telegram的端到端加密默认是关闭的
是的，它有E2E“秘密聊天”，但您需要手动激活它。像Threema或Signal这样的应用程序是更好的选择，因为默认情况下所有内容都是端到端加密的。

Telegram使用电话号码
电报将帐户与电话号码相关联。信使验证用户在注册帐户时可以访问电话号码（通过短信或通过电话发送的验证码）。对于可以访问电话公司系统的攻击者（例如SS7注入，或国家电话运营商）劫持帐户的验证码非常简单。只需将SMS /呼叫重定向到受攻击控制/可见性的位置即可。
这种攻击已在野外使用了很多次。起初只有来自伊朗的电报账号被劫持的报道。然后，在俄罗斯的一个帐户劫持被记录在案并公之于众。显然，至少有一些民族国家正在使用这种技术来劫持劫持账户。
Telegram添加了一个额外的安全功能（但不是必需的）来解决这种攻击 – 密码。如果为帐户设置了密码，则发送到电话号码和密码的身份验证都需要访问新设备上的帐户。

云消息传递
所有非端到端加密聊天都会自动备份到Telegram服务器。当用户从其他设备访问其帐户时，他们可以使用他们的整个聊天记录。这是一场安全噩梦。这意味着帐户泄露会将历史数据暴露给对手，而不仅仅是在妥协期间。存储敏感数据始终是一个危险的过程。

默认设置会诱发不安全的操作
默认情况下，邮件不是端到端加密的。没法加密现有会话。除非用户必须选择“新秘密聊天”，然后开始聊天。这很容易出错。最可能的情况是，人们会错误地点击他们想要与之交谈的联系人，而不是经历设置“秘密聊天”的多步骤过程。允许出错的工具会助长操作错误。致命失误在所难免。

联系人信息窃取
用户使用Telegram注册帐户时，该应用程序可以把整个联系人数据库上传到Telegram的服务器（iOS上可选）。这使Telegram能构建一个包含所有用户的巨大社交网络的图谱。使用Telegram时保持匿名是极其困难的，因为与他们交流的每个人的社交网络都是暴露的（在已知服务器）。
联系人是非常有价值的信息。我们知道国家安全局竭尽全力从即时通讯服务中窃取它们。在移动设备上，联系人列表更为重要，因为它们经常与现实世界身份相关联。

大量元数据
任何使用手机的东西都会暴露出各种各样的元数据。除了通过Apple和Google的消息传递服务的所有通知流之外，还有进出这些服务器的IP流量以及Telegram服务器上的数据。我敢打赌，这些服务器已经被国家情报部门所破坏，所有这些数据都被定期扒库。
这个元数据会暴露谁与谁交谈，在什么时间，他们所在的位置（通过IP地址），说了多少等等。这些流程中有大量信息可以弥补缺乏访问权限的内容（即使，假设加密是可靠的）。

如果您使用“端到端”聊天，Telegram可以看到您正在写的内容
Telegram提供了一个名为“链接预览”的功能，默认情况下可用于非加密聊天，但是，即使您使用端到端“秘密聊天”，Telegram应用程序依然会询问您是否要使用“链接预览”，并且预测可以在在服务器端完成。Telegram怎么知道你在写什么链接？如果你正在使用“秘密聊天”，他们还可以阅读你的消息吗？（不确定，但这绝对是一个灰色地带）。

本地存储未加密
仅当您使用“Secret chat”秘密聊天模式时，本地存储才会被加密。

Telegram使用“自主研发”的MTProto加密协议
Telegram的安全性基于其“自主研发”的MTProto加密协议构建。我们都知道密码学的第一条规则是“不要自主研发”，如果你不是训练有素的密码学家更是如此，显然Telegram的工程师们不是。
从高层的角度来看，Telegram允许两个设备使用Diffie-Hellman密钥交换来交换长期密钥。之后，这两个设备可以使用此密钥使用MTProto对称加密方案来交换加密消息。简而言之，MTProto是以下组合：

• 一种鲜为人知的操作模式，即无限修饰扩展（IGE）。
• 短期密钥推导机制。
• 对明文进行完整性检查。

这是MTProto的抽象描述：

MTProto Encryption

Long-Term key: The sender and the receiver share a long term-key K of length λ. (In MTProto λ = 2048 bits and the key is obtained by running the Diffie-Hellman Key-Exchange over Z∗p).
Payload: The payload x = (aux,rnd,msg,pad) is obtained by concatenating:

Some auxiliary information aux.
A random value rnd (in MTProto this has length 128 bits).
The message msg.
Some arbitrary padding pad such that |x| mod B = 0, where B is the block length; For technical reasons this is never more than 96 bits (and not 120 bits as described by the official documentation).

Authentication Tag: MTProto employs a hash function:
Tag: {0,1}^∗ → {0,1}^h
For authentication purposes. This is used to compute:
tag = Tag(aux,rnd,msg)
(crucially, pad is not part of the input of the authentication tag). In MTProto, Tag = SHA-1 and h = 128 bits.
Short-Term Key Derivation: MTProto employs a hash function. KDF: {0,1}^λ+h → {0,1}^κ+2B
for key derivation purposes. This is used to compute: (k,x0,y0) = KDF(K,tag)
of length (κ,B,B) respectively. In MTProto the output of KDF is obtained by (a permutation of) the output of four SHA-1 invocations, which in turn take as input (a permutation of) the tag and (different) portions of the long term key K.
IGE Encryption: MTProto employs an efficiently invertible pseudorandom permutation
F,F−1:{0,1}^κ×{0,1}^B → {0,1}B
to implement the IGE mode of operation. Let
x1,…,xy be the y blocks of the payload, each of length B, then IGE computes
yi=Fk(xi ⊕ yi− 1) ⊕ xi−1 (where x0,y0 are defined in the previous step). In MTProto
F=AES with κ = 256 bits and B = 128 bits.
Resulting Ciphertext: The output of MTProto is c= (tag,y1,…,yz)

MTProto Decryption

Input Parsing: The ciphertext c is parsed as c = (tag,y1,…,yz)
Short-Term Key Recomputation: The short-term key and the initialization blocks are recomputed as (k,x0,y0) = KDF(K,tag)
IGE Decryption: The payload is recovered by computing: xi=yi−1 ⊕ F−1k(yi ⊕ xi−1) and (x1,…,xy) is parsed as (aux,rnd,msg,pad).
Tag Verification: The decryption checks if tag (?=) Tag(aux,rnd,msg) and, if so, outputs msg (or if not otherwise).

有趣的是，如果Telegram客户端收到格式错误的密文，它只会丢弃该消息，并且不会通知发件人该错误。这意味着网络攻击者很难检测解密是否成功执行（因此似乎不可能运行Bleichenbacher式攻击[基于RSA加密标准PKCS的协议的密文攻击]） 。但是，我们不能排除位于同一客户端并共享资源（例如内存，CPU等）的攻击者可能能够使用其他通道检测解密是否（以及如何）失败。

MTProto达不到IND-CCA的安全性

在这里，我简要介绍两种攻击，表明MTProto达不到IND-CCA的安全性。我们假设读者熟悉IND-CCA安全性的概念（如果没有，请参阅https://en.wikipedia.org/wiki/Ciphertext_indistinguishability）。有关攻击（和实验验证）的更多详细信息，请参见[ http://cs.au.dk/~jakjak/master-thesis.pdf ]。
我再一次强调，这些攻击只是理论上的，我们没有办法将它们变成完全明文的恢复。然而，我们认为这些攻击是另一个证据[ https://eprint.iacr.org/2015/428.pdf ]，说明自行设计加密协议大多数情况下都不是一个好主意。

第一种攻击: Padding-Length Extension
Given a ciphertext:
c= (tag,y1,…,yz) which encrypts a payload x= (aux,rnd,msg,pad)
the attacker picks a random block
r ← {0,1}B and outputs
cz= (tag,y1,…,yz,r)
When this is run via the decryption process, the resulting payload is
xz= (aux,rnd,msg,padz) where padz= (pad,pad∗) where:

pad∗ is randomly distributed.
The length of |padz| is larger than the block length B. However, since the length of the padz is not checked during decryption, and padz is not an input to the authentication function Tag, decryption outputs msg with probability 1.

第二种攻击: Last Block Substitution
Given a ciphertext
c= (tag,y1,…,yz) which encrypts a payload x= (aux,rnd,msg,pad)
the attacker picks a random block
r ← {0,1}^B and outputs
c′= (tag,y1,…,y`−1,r)
When this is run via the decryption process, the resulting payload is
x′= (aux,rnd,msg′,pad′) When this is run via the decryption process, the resulting payload is
x′= (aux,rnd,msg′,pad′)

设P = | pad | 如果是原始填充的长度，则认为msg’的最后B-P位是随机分布的（由于在IGE解密中使用PRF）。因此，我们有msg’= msg，概率为2P-B，在这种情况下，验证标签的验证成功，解密输出msg。根据MTProto的官方描述，填充长度在0到120位之间，这意味着在最好的情况下，上述攻击成功的概率为2 ^ -8。然而，实验验证表明情况并非如此，并且填充的长度实际上在0到96位之间（这是由于对象在Java中被序列化的方式）。所以我得出结论，在最好的情况下，这次攻击成功的概率为2 ^ -32，

结论

Telegram使用的对称加密方案无法实现理想的安全性概念，例如在所选择的密文攻击或经过身份验证的加密下的不可区分性。对于第一种攻击，可以通过打补丁的方式向前兼容没有打补丁的（诚实）发件人。但第二种攻击的补丁无法实现这种向前兼容性，只有双方都打补丁的用户之间才能通信。因此，我很好奇下一版本的Telegram是会使用打补丁的MTProto修补版本，还是业界充分研究的，加入身份认证的加密方式。
我认为后者是唯一明智的选择，因为虽然MTProto的修补版本不会受到本说明中描述的攻击的影响，但这并不能保证不存在其他攻击。另一方面，经过充分研究的认证加密方案提供了更强大的安全保障。另外，MTProto似乎不比用于认证加密的许多可用选项更有效，例如，在计数器模式下使用AES（其可以比IGE更好地并行化）与例如HMAC一起使用加密然后MAC。
所以说，从普适的安全性定义来说，当下的Telegram绝对是不安全的，真正关注安全和隐私的用户可以选择Signal Messenger暂时代替。

本文由Bcamp授权转载