MTProto 모바일 프로토콜

MTProto 모바일 프로토콜

우리 확인해 주시기 바랍니다 기술적 경향에 대한 질문과 대답 . 
클라이언트 개발자는 준수해야하는 보안 지침 .

관련 기사

• 모바일 프로토콜 : 상세 설명
• 인증 키를 생성
• 인증 키 생성 : 예
• 모바일 프로토콜 : 서비스 메시지
• 모바일 프로토콜 : 메시지에 대한 서비스 메시지
• 이진 데이터 직렬화

• TL 언어

• MTProto TL-스키마

• 클라이언트 소프트웨어 개발자를위한 보안 가이드 라인

일반 설명

프로토콜은 모바일 장치에서 실행되는 응용 프로그램에서 서버 API에 대한 액세스를 위해 설계되었습니다. 이는 웹 브라우저 같은 어플리케이션이 아니라고 강조되어야한다.

프로토콜은 사실상 세 개의 독립적 인 구성 요소로 나누어진다 :

• 높은 수준의 구성 요소 (API 쿼리 언어) : API 쿼리 및 응답이 바이너리로 변환된다 방법을 정의 메시지 .
• 암호화 (권한 부여) 층 : 메시지 전송 프로토콜을 통해 전송되기 전에 암호화하는 방법을 정의한다.
• 전송 컴포넌트는 : 클라이언트 및 (예컨대, HTTP, HTTPS, TCP, UDP 등) 어떤 다른 기존의 네트워크 프로토콜을 통해 메시지를 전송하는 서버에 대한 방법을 정의한다.

이 설정에 대한 질문이 있으십니까? - 확인 고급 FAQ를 !

주 1 : 각각의 평문 메시지는 항상 다음의 데이터 구성 요소와 공지 된 문제점에 대해 강력한 시스템을 확인하기 위해 암호 해독시 점검 할 포함 MTProto 암호화한다 :

• 서버 소금 (64 비트)
• 세션 ID
• 메시지 시퀀스 번호
• 메시지 길이
• 시간

: 2 주 우리의 사용에 대한 추가 의견을 참조 IGE , SHA-1 및 수정 암호화 앤 맥 .

간단한 구성 요소 요약

높은 수준 구성 요소 (RPC 쿼리 언어 / API)

상위 레벨 구성 요소, 클라이언트와 서버의 과거의 관점에서 메시지 내부 세션 . 세션 오히려 특정 HTTP / HTTPS / TCP 연결보다 (보다 정확하게는, 응용 프로그램) 클라이언트 디바이스에 부착된다. 또한, 각 세션에 부착되는 사용자 ID 키 인증이 실제로 수행되는 의해.

열려있을 수 있습니다 서버에 여러 연결; 메시지는 (가장 자주, 그 경우이더라도 쿼리에 대한 응답이 반드시, 원래의 질의를 수행 같은 연결을 통해 반환하지 않은 접속들을 통해 양방향으로 전송 될 수 있지만, 어떠한 경우에도 메시지가 될 수있다 다른 세션에 속하는 연결)를 통해 반환. UDP 프로토콜이 사용되는 경우, 질의 응답이 전송되었던되는 것과 다른 IP 주소에 의해 반환 될 수있다.

메시지의 여러 가지 종류가 있습니다 :

• RPC 호출 (서버 클라이언트) : API 메소드 호출
• RPC 응답 (클라이언트 서버) : RPC 호출의 결과
• 메시지 확인 응답을 수신 (또는 오히려, 메시지 집합의 상태 통지)
• 메시지 상태 문의
• 멀티 메시지 또는 용기 (여러 메시지를 보관 용기, 예를 들어, HTTP 연결을 통해 한 번에 여러 RPC 호출을 전송하는 데 필요한, 또한 컨테이너가 GZIP을 지원할 수있다).

하위 레벨 프로토콜의 관점에서, 메시지는 4 또는 16 바이트 경계를 따라 정렬 된 이진 데이터 스트림이다. 메시지의 처음 몇 개의 필드가 고정되고, 암호화 / 인증 시스템에 의해 사용된다.

개인 또는 용기 내부 중 각 메시지는, 이루어져 메시지 ID (64 비트, 아래 참조), 세션 내에서 메시지 시퀀스 번호 (32 비트), 길이(32 비트 바이트 메시지 본문) 등 본체 (4 바이트의 배수가되는 모든 사이즈). 용기 또는 하나의 메시지가 전송되는 경우 외에도,내부 헤더 가기 (아래 참조)를 첨가하고 전체 메시지를 암호화하고, 외부 헤더는 메시지의 상단 (64 비트에 위치 키 식별자 및 128 비트 메시지 키 ).

메시지 바디는 일반적으로 32 비트 이루어져 메세지 입력 형 의존적이어서 파라미터 . 특히, 각 RPC 함수는 해당 메시지 유형을 갖는다. 자세한 내용은 다음을 참조 이진 데이터 직렬화 , 서비스 메시지 : 모바일 프로토콜 .

모든 숫자는 리틀 엔디안으로 기록됩니다. 그에는 OpenSSL 라이브러리가하는 일이기 때문에, RSA와 DH에서 사용되는 매우 큰 숫자 (2048 비트)는 빅 엔디안 형식으로 작성됩니다.

인증 및 암호화

메시지 (또는 멀티 메시지) 이전에 전송 프로토콜을 사용하여 네트워크를 통해 전송되고, 이는 어떤 방식으로 암호화하고, 외부 헤더 인 메시지의 상단에 추가된다 : 64 비트 키 식별자 ( 즉, 고유하게 식별하는 인증 키 서버뿐만 아니라 사용자 )와 128 비트의 메시지 키 . 메시지 키와 함께 사용자 키는 AES-256 암호화를 사용하여 메시지를 암호화 무엇 실제 256 비트 키를 정의한다.암호화 될 메시지의 초기 부분은 가변 데이터 (세션, 메시지 ID, 시퀀스 번호, 서버 염) 명백하게 메시지 키에 영향을 포함하는 것이 주 (따라서 AES 키와 IV). 메시지 키 (세션 등, 메시지 ID를 포함) 메시지 본문의 SHA1의 128 저차 비트들로 정의된다. 여러 부분 메시지는 하나의 메시지로 암호화됩니다.

기술 사양에 대한 내용은 모바일 프로토콜 : 상세 설명
클라이언트 응용 프로그램이 가장 먼저해야 할 일이 있습니다 인증 키 생성 정상적으로를 처음 실행하면 생성되고 변경되지 거의 않습니다.

프로토콜의 주요 단점은 침입자가 수동적으로 메시지를 차단하고 어떻게 든 (장치를 훔치고, 예를 들어) 인증 키를 도용하는 모든 차단 된 메시지를 해독 할 수있을 것입니다 factum를 게시 . 이것은 아마도 (a 장치를 훔치는, 하나는 아무것도 복호화하지 않고 단말기에 캐시 된 모든 정보에 접근 할 수있는) 너무 많은 문제가 아니다; 그러나, 다음 단계는이 약점을 극복하기 위해 수행 될 수있다 :

• 세션 키는 디피 - 헬만 프로토콜을 사용하여 생성 된 AES 및 파라미터를 선택하는 권한과 메시지 키와 함께 사용. 이를 만들려면 클라이언트가 새로운 세션을 생성 한 후 가장 먼저해야 할 일은 ( "세션 키를 생성") 세션 내 모든 후속 메시지를 사용하여 암호화 그러자 서버가 응답 할 수있는 서버에 특별한 RPC 쿼리를 보낼 수있다 세션 키뿐만 아니라.
• (텍스트)의 암호와 클라이언트 디바이스에 저장된 키를 보호; 이 암호는 결코 메모리에 저장되지 않고, (프로그램 설정에 따라) 더 자주 애플리케이션을 시작하거나 사용자에 의해 입력된다.
• 사용자 단말기 (캐시)에 저장된 데이터는 또한 차례로, 암호로 보호하여야한다, 인증 키를 이용하여 암호화함으로써 보호 할 수있다. 이어서, 암호에도 그 데이터에 액세스하도록 요구 될 것이다.

시간 동기화

클라이언트 시간이 서버 시간부터 넓게 발산하는 경우, 서버는 때문에 (밀접 작성 시간과 관련된) 무효 메시지 식별자, 클라이언트 메시지, 또는 그 반대를 무시 시작할 수있다. 이러한 상황에서, 서버는 (명시 적으로 특별한 RPC 동기화 요청에서 클라이언트에 의해 제공되거나, 클라이언트로부터 수신 된 최신 메시지의 키와 동일하거나 클라이언트에게 정확한 시간 및 일정한 128 비트 염을 함유하는 특별한 메시지를 보낸다 ) 현재 세션 동안. 이 메시지는 (시간 차이는 중요하지만, 아직까지 무시되고 클라이언트의 메시지에 포함되지 않는 경우), 다른 메시지도 용기 내의 첫번째 하나 일 수있다.

수신 된 이러한 메시지 또는 채 컨테이너를 갖는 클라이언트는 먼저하고 검증한다 (단순히 서버의 시간과 그 이후의 "올바른"시간을 계산할 수 있어야하는 자신의 차이를 저장하는 효과) 시간 동기화를 수행 정확성에 대한 메시지 식별자가.

보정을 게을리 한 경우, 클라이언트는 메시지 식별자의 단 조성을 보증하는 새로운 세션을 생성 할 것이다.

교통

외부 헤더 (이하, 함께 암호화 된 용기의 전달을 활성화 페이로드 ) 클라이언트에서 서버에 다시합니다. 전송의 세 가지 유형이 있습니다 :

• HTTP
• TCP
• UDP

우리는 먼저 두 가지 유형을 조사한다.

HTTP 전송

HTTP를 통해 구현 / 사용하지 않는 기존의 TCP 포트 80 HTTPS를 통해 실행 (킵 얼라이브)와 1.1; 상기 암호화 방법 대신에 사용된다.

HTTP 연결은 수신 된 가장 최근의 사용자 질의에 지정된 (+ 세션 키 식별자, 또는 오히려) 세션에 부착된다; 일반적으로 세션은 모든 쿼리에서 동일하지만, 교활 HTTP 프록시가 손상 될 수있다. 서버는 동일한 세션에 속하는 않는 HTTP 접속에 메시지를 반환 할 수 있고, 그 서버의 차례가 아니면 (HTTP 요청 응답은 아직 전송되지 않은하기 위해 클라이언트로부터 수신되었다).

다음 전반적인 배열이다. 클라이언트는 서버에 하나 이상의 연결 유지 HTTP 연결을 엽니 다. 하나 이상의 메시지들이 송신 될 필요가 있다면, 이들은 화되는 페이로드 가 데이터 페이로드로 전송되는 URL / API에 POST 요청에 따른다. 또한, 콘텐츠 길이 ,Keepalive는 , 그리고 호스트가 유효한 HTTP 헤더입니다.

쿼리를 수신하면, (컨테이너 만의 영수증을 인정) (조회가 짧은 시간 초과 다음과 같은 응답을 필요로하는 경우) 조금 기다려 즉시 더미 응답을 반환 할 수는 서버. 어떤 경우에, 응답 메시지의 수를 포함 할 수있다. 서버는 동시에이 세션에 대해 보유 될 수있는 다른 메시지를 전송할 수도있다.

또한, 그들은 즉시 반환 서버가 세션에 대한 메시지가있는 경우 최대 타임 아웃 T.을 송신한다 (단 HTTP 연결 유효) 특별한 긴 폴 RPC 쿼리가 존재; 그렇지 않으면, 대기 상태는 서버가 클라이언트가 메시지 또는 T 초 경과 할 때까지로 입력된다. 이벤트가 T 초의 기간에 발생하지 않으면, 더미 응답 (특별 메시지)가 리턴된다.

서버가 클라이언트에 메시지를 보낼 필요가있는 경우, 요구되는 세션에 속하는 메시지에 대한 응답 용기에 첨가 그러자 (긴 폴 포함) "HTTP 요청에 응답"상태에 HTTP 연결을 검사 사용자가 연결하여 전송. 전형적인 경우에, 서버가 곧 많은 메시지 세션을 갖 사태에 대해 추가적인 대기 시간 (50 밀리 세컨드)이있다.

더 적합한 HTTP 연결을 사용할 수없는 경우, 메시지는 현재 세션의 송신 큐에 배치된다. 영수증 명시 적으로 또는 간접적으로 클라이언트에 의해 확인 될 때까지 그러나이 어쨌든 자신의 길을 찾을 수 있습니다. 같은 HTTP 접속에 다음 질의를 전송하는 HTTP 프로토콜에 대해 암시 적 확인 응답으로 간주한다 (HTTP 프로토콜은 또한 명시적인 확인 응답이 전송 될 것을 요구하지 더 이상); 다른 경우에, 클라이언트는 적절한 시간 (그 다음 요청을위한 용기에 첨가 될 수있다) 내에서 명시적인 확인 응답을 반환해야한다.

중요 : 확인 응답 시간에 도달하지 못하면, 메시지는 (다른 용기에, 아마도) 재전송 될 수있다. 당사자들은 자율적으로 이에 대한 준비가되어 있어야받은 가장 최근의 메시지의 식별자를 저장 (및 중복보다는 반복 작업을 무시)해야합니다. 영원히 저장된 식별자를 가지는하게하지 않기 위해, 특별한 존재 가비지 콜렉션 메시지 식별자 조성을 활용 메시지.

송신 큐 오버 플로우 나 메시지가 10 분 이상 큐에 남아있는 경우, 서버를 잊어 버린 경우 (또는로 전송 교환 , 어떤 천재가 필요하지 않습니다). 서버가 버퍼 공간이 부족할 경우가 더 빨리 발생할 수 있습니다 (예를 들어 있기 때문에 많은 수의 연결의 결과로 심각한 네트워크 문제로 인해 단절되는 것을).

TCP 전송

이것은 HTTP 전송과 매우 유사하다. 또한 포트 80을 통해 구현 될 수있다 (모든 방화벽을 침투), 심지어 같은 서버의 IP 주소를 사용합니다. 이 상황에서, 서버 (HTTP를 들어, POST가있다) 제 사 수신 바이트에 기초하여, 접속을 위해 사용되어야 HTTP 또는 TCP 프로토콜 여부를 이해한다.

TCP 연결이 만들어지면,이 제 1 사용자 메시지 전송 세션 (및 인증 키)에 할당하고,이어서이 세션을 위해 독점적으로 사용된다 (다중화 배치는 허용되지 않음).

페이로드 (패킷)은 클라이언트 또는 클라이언트에서 서버간에 전송 될 필요가있는 경우에는 다음과 같이이를 캡슐화 : 4 길이의 바이트 길이, 시퀀스 번호, CRC32를 포함하도록 (앞 첨가되며 의하여 항상 나누어 4)이 TCP 접속 내의 패킷의 시퀀스 번호 (전송 된 첫번째 패킷과 4 바이트가 0으로 번호가되고, 단부 (길이, 시퀀스 번호, 페이로드에 다음 중 하나 일 등), 4 CRC32 바이트 함께).

동일한 프로토콜의 요약본이있다 : 클라이언트는 전송하면 0xef 다음 패킷 길이는 단일 바이트로 인코딩된다 (: 첫 번째 바이트 (** 만 전에 첫 데이터 패킷에 중요 **)로 0x01..0x7e = 데이터 길이를 4로 나눈 또는 에서 0x7f는 데이터 자체 (일련 번호 및 CRC32이 추가되지 않음) 다음 4로 나눈 세 길이 바이트 (리틀 엔디안)) 하였다. 이 경우, 서버 응답은 (서버에서 전송하지 않는 동일한 모양 0xef 첫번째 바이트로).

프로토콜의 전체 및 축소 된 버전의 빠른 응답에 대한 지원을해야합니다. 이 경우, 클라이언트는 질의 패킷에서 가장 높은 차수의 비트 길이를 설정하고, 서버는 별도의 패킷으로 특별한 4 바이트로 응답한다. 그들은이 일반적인 서버 응답 패킷의 길이가 아니라고 확실하게 설정, 최상위 비트를 가진 패킷의 암호화 부 (32)의 고차 비트 SHA1이다; 축소 된 버전을 사용하는 경우, 이러한 BSWAP 4 바이트에인가된다.

모든 메시지를 명시 적으로 인정해야합니다 TCP 전송에 대한 묵시적 승인이 없습니다. 이 짧은 순서로 전송되는 경우 가장 자주, 승인은 다음 질의 나 응답과 함께 컨테이너에 배치됩니다. 예를 들어, 거의 항상 RPC 쿼리를 포함하는 클라이언트 메시지의 경우 : 확인 응답은 일반적으로 RPC 응답으로 도달한다.

에러가 발생하면, 서버는 그 페이로드 에러 코드로 4 바이트로 구성 패킷을 전송할 수도있다. 예를 들면, 에러 코드 (403)는 해당 HTTP 에러가 HTTP 프로토콜에 의해 반환되었을 경우에 대응한다.