How Secure is TextSecure?

<How Secure is TextSecure?>

 NSA와 GCHQ같은 intelligence services에 의해 수행되는 대중 감시에 대한 공식 발표는 사람들이 그들의 인터넷 상의 대화에 대한 보안, 프라이버시를 위한 방안을 찾도록 했습니다.  페이스북이 WHATSAPP을 인수하고 보안 통신을 제공한다는 대체제들의 새로운 유저 유입은 상당히 증가했습니다.  

 많은 관심을 끈 메시지 어플리케이션중 하나가 TEXTSECURE입니다.  TextSecure는 종단간 암호화를 이용해 기밀 메시지를 보낼 수 있습니다.  본 논문에서는 TEXTSECURE의 암호 프로토콜을 살펴볼 것입니다.  

 Instant Messaging(IM), 문자메시지는 10년도 더 이전부터(논문 기준) 대화 형식으로 사용하기 편리한 점에서 많은 인기를 끌었습니다.  하지만 e-mail과 달리 PGP나 s/MIME과 같은 보안 메커니즘을 사용할 수 없습니다.  초창기, MSN이나 야후 메신저들은 보안 케머니즘을 전혀 제공하지 않았습니다.  혹은 s/MIME과 유사한 메커니즘이나 기밀성만 만족시키는 암호화를 했습니다.  요즘은 대부분의 클라이언트들이 TLS를 통해 최소한 client-to-server 암호화는 제공해줍니다.  OTR communication이 가능하죠.

 스마트폰이 대중화되면서 문자 메시지의 사용이 늘었는데 WHATSAPP나 SKYPE들은 보안 메커니즘을 신경써줬는지 알 수 없었습니다.  초기에는요.  NSA 등의 대중 감시 이슈가 나오면서 안전한 문자 메시지 솔루션들이 구현되었습니다.

 앞으로 Unknown Key-Share attack에 대해서 볼 것이고 TEXTSECURE가 인증, 기밀성을 만족하는지를 입증할 겁니다.

1. TEXTSECURE PROTOCOL

 ECDH operations을 위해 구글의 안드로이드 네이티브 라이브러리로 curve25519를 이용하고 있습니다.  대칭암호화를 위해서는 패딩이없는 카운터모드, PKCS5 패딩의 CBC모드를 이용한 AES를 사용합니다.  무결성과 인증에는 HMACSHA256이 쓰입니다.  

 데이터 채널을 통한 푸쉬 메시지는 central server인 'TS'에 의존하며 TS를 통해 HTTPS를 사용하는 REST-API를 씁니다.  TS의 인증은 스스로하며 CA의 인증은 TEXTSECURE 애플리케이션에 하드코딩되어 있습니다.  실제 메시지 전송은 GCM(Google Cloud Messaging)을 통해 이루어집니다.

A. TextSecure Protocol Flow

 TEXTSECURE의 프로토콜은 크게 등록, 최초 메시지의 전송/수락, 다음 메시지 전송, 응답 전송으로 구분됩니다.

 클라이언트가 통신하기 전에 키값을 생성하고 TS에 등록할 필요가 있습니다.  또한 안드로이드 네이티브 라이브러리로 제고오디는 SHA1PRNG를 이용해 패스워드, 등록 ID, 2개의 키를 선택합니다.  MAC를 계산할 때는 HMACSHA256을 사용합니다.  

 Pa가 Pb에게 메시지를 보낼 때 Pb의 공개키를 TS로부터 받아 공유비밀과 메시지를 생성하여 TS에게 전달합니다.  TS는 대칭 long-term 키를 Pb와 공유합니다.  이는 Pb에게 보낼 Pa의 메시지를 암호화하는데 쓰입니다.  TS가 암호화된 메시지를 Pb로의 전달을 위해 GCM에게 넘겨주고, Pa가 다음 메시지를 Pb에게 전송하고 싶으면 존재하는 키값을 이용해 생성된 함수f를 이용해 새로운 키를 생성합니다.

B. Detailed Description of Messages

1). Registration : 다음 Figure 1은 등록 프로세스를 나타냅니다.

TEXTSECURE로 등록하기 위해 사용자 Pa는 폰 번호를 전송함으로서 토큰을 받습니다.  TS는 문자 메시지나 전화를 통해 랜덤토크를 전송합니다.  

2) Sending an Initial Message : 데이터를 교환하기 위해 새로운 세션을 만들 때에는 세가지 메인 암호화 생성 블록이 적용됩니다.  또한 키 관리 프로토콜은 전방향 안전성과 후방향 안전성을 제공합니다.

3) Follow-up Message : Pb가 응답하기전에 Pa가 메시지를 또 보낸다면 새로운 키를 생성하여 위 과정을 반복합니다.

3. ISSUE WITH TEXTSECURE

A. MAC Image Space Only Partially Used

 TEXTSECURE는 MAC을 계산하기 위해 HMACSHA256을 사용합니다.  그런데 256 bit의 MAC 중에 최초 64bit만 사용합니다.  이는 NIST에서 권장하는 80bit의 MAC 길이에 못미칩니다.

B. Unknown Key-Share Attack

 Pa는 Pe를 Pb로 착각하고 키를 공유할 수 있습니다.  이 때 사용되는 방식은 중간자공격과 비슷합니다.

C. Mitigation of Authentication Issue

 TEXTSECURE에는 인증 이슈가 있습니다.  이를 해결하는데는 두 가지 방법이 있는데 하나는 전자서명을 이용하는 방식입니다.  다음이 그 프로세스입니다.

 (1) Signature-based Cryptographic Authentication

1) Pa는 SHA1PRNG를 이용해 토큰 ra를 찾고 이 토큰을 포함하는 QR코드1을 생성합니다.

2) Pb는 Pa의 QR코드1을 스캔하여 Pa의 토큰에 해당하는 서명을 자신의 장기간 개인키로 만듭니다.  그리고 ra와 자신의 토큰 rb를 포함해 QR코드2를 생성합니다.

3) Pa는 Pb의 QR코드2를 스캔하고 Pb의 서명을 Pb의 장기간 공개키를 이용하여 식별합니다.  이 때 Pa의 토큰을 이용한 서명이라는 것을 확인할 수 있습니다.  그리고 자신 또한 ra와 rb를 이용해 자신의 개인키로 서명을 생성합니다.  이 서명을 포함한 QR코드3을 만듭니다.

4) Pb가 Pb의 QR코드3을 스캔하여 Pa의 공개키로 ra와 rb를 식별합니다.  

이 방법은 논문에서 제안한 것으로 TEXTSECURE에는 전자서명 방식이 포함되어 있지 않습니다.  그래서 다음 방법을 제안하였습니다.

 (2) Alternative Authentication Method

이는 DH방식과 비슷합니다.  위 과정이 끝난 후 반대로 Pa가 Pb를 식별하는 과정도 진행합니다.  

4. SECURITY OF TEXTSEUCRE KEY EXCHANGE AND MESSAGING

 이 장에서는 각각의 프로토콜을 통한 시나리오를 통해 제시한 프로토콜이 공모가 없을 경우 각 파티(기밀성을 공유하는)는 같은 공개키를 가질 수 없다는 것을 보여줍니다.  이를 통해 TEXTSEUCRE 암호화가 one-time stateful and authenticated 해 질 수 있다는 것을 나타내죠.

 최근 IS와 관련된 채널을 텔레그램이 다수 삭제한 것이 공개되었습니다.  텔레그램은 카카오톡 감청 이슈 이후 암호화 메신저 앱으로 많이 알려졌었죠.  하지만 이번 사건들 이후로 매시지 앱에 다시 관심이 쏠리고 있습니다.  카카오톡 때 처럼 한국에서 그렇다는건 아니구요.  이번 논문은 단순히 공개키 기반, 암복호화 프로토콜만 언급하는 것을 넘어서 TEXTSECURE의 프로토콜을 보안 측면에서 확실히 분석했습니다.  첫 논문 포스팅인 'Guess ~'에서도 메시지 애플리케이션에 대해 봤었는데 그 때는 애플리케이션들에 대한 대략적인 오버뷰를 봤다면 여기서는 더 깊게 보고 있습니다.  단순 암복호화 수준을 넘는 방법들에 대해 심화학습할 수 있는 논문입니다.