MTProto ，telegram的端到端加密技术之一：Architecture概述（翻译）

MTProto，Telegram的端到端加密技术之一：Architecture概述（翻译）MTProto是Telegram为防止监控而实现的端到端加密协议。以下是该协议架构的概述翻译：一个简单的总结（和ISO/OSI七层协议栈对照）应用层：顶层RPC应用接口表示层：类型语言（Type Language）会话层：MTProto会话传输层：MTProto传输层，MTProto模糊（obfuscation）层（可选），以及传统的传输层协议MTProto协议运行在传输层协议（如TCP、UDP）和HTTP/HTTPS/WS/WSS协议之上。协议设计概述MTProto协议是为移动端应用接入服务器而设计的，注意网页端并不属于这个类型。协议划分为虚拟的三个独立的组件：顶层组件（RPC查询语言/API）：定义了API查询和回复如何被转化为二进制信息。加密（鉴权）层：定义了在传输层发送信息之前信息是如何被加密的。传输组件：定义了客户端和服务器在已有的网络协议（如HTTP、HTTPS、TCP、UDP、WS、WSS）上发送信息的方法。注：Telegram使用MTProto 2.0，1.0版本已经放弃维护。这些名词在后续有机会的话会逐一解释简单的组件描述顶层组件（RPC查询语言/API）从顶层组件的角度看，客户端和服务器在一个会话（session）中交换消息（message）。一个会话依附于客户端设备（准确来说是应用）而不是一个特定的websocket/http/tcp/https连接。每个会话依附于一个已经完成了鉴权的User Key ID。可以打开与一个服务器的多个连接。连接是双工的，即消息可以从连接的任意一端发出。一个查询的回应可以不从同一个连接发回（但一般如此），但必定在同一个会话中发回。在UDP协议中，一个查询的回应可以从和查询的目的IP不一样的IP地址发出。消息有多种类型：RPC调用（客户端-服务器）RPC回应（服务器-客户端）确认接收消息（或一坨消息的状态的通知）消息状态查询一坨消息/容器（一个容器容纳多条信息，需要在一个http连接上同时发送多个RPC调用；另一个容器也许也支持gzip）从底层协议的角度看，一条消息是一条满足4字节或16字节边界对齐的二进制数据流。信息的前几个域是固定的，被加密/鉴权系统所使用。每条消息，无论是在容器中的还是单独的，都由以下几部分组成：消息ID（64bit）消息在会话中的序列号（32bit）消息主体（body）长度（32bit）消息主体（长度为4字节的倍数）当消息（单独或者在容器中）被发送之后，会被加上一个内部头（internal header）。被加密之后，还会被加上一个外部头（external header）。消息主体一般含有一个32bit的消息类型和一些类型依赖的参数。特别地，每个RPC函数都有一个相应的消息类型。所有的数字一般都用小端法书写，但在RSA、DH中使用的很大的数字（2048bit）一般用大端法格式，因为OpenSSL库就这样。鉴权和加密在一条消息在其他传输层协议之上被发送之前，它以一种特定方式被加密，并且会被加上一个外部头，包含一个64bit的用户Key ID（唯一确定用户和服务器之间的一对鉴权Key）和一个128bit的消息Key。一个用户Key和一个消息Key定义了一个256bit的Key，被用来使用AES-256加密方式加密消息。注意一条消息被用于加密的最初部分包含了变量（会话，消息ID，序列号，服务器salt），会很明显地影响消息Key（以及AES Key）。消息Key被定义为SHA加密之后的消息主体的中间的128bit，也包括了填充字节，前面的部分是鉴权Key当中拿来的32字节。多条消息的整体作为一整条消息被加密。一个客户端应用要做的第一件事就是创建一个鉴权Key，一经运行，几乎永不更改。协议最原则性的一个缺陷就是如果一个被动拦截消息而占有了鉴权Key（比如偷走了一台设备）的入侵者就能解密所有拦截了的消息，但这不是什么大问题（因为偷了设备之后本来不用解密就能获得所有信息）。然而，以下的步骤能克服这个弱点：会话Key用Deffie-Hellman协议生成，和鉴权和消息Key链接去选择AES的参数。创建这些，一个客户端在创建会话之后需要做的第一件事就是向服务器发送一个特殊的RPC查询（“generate session key”），服务器回复，接下来的所有消息也都会用这个会话Key加密。（用文本密码）保护好客户端设备上的Key。这个密码不存储在内存里，用户每次启动应用（或者更频繁地）手动输入。用户设备上缓存或存储的数据也可以被用一个鉴权Key加密的方式保护，但是这个Key也需要被密码保护。时间同步如果客户时间和服务器时间差别太多，一个服务器就可能开始忽略客户端消息，或者反过来，因