그것이 알고싶다 – E2E & PFS

정말 정말 끝까지 신경을 안쓰고 버티려고 했는데..

결국 글을 쓰게 되는군요.. 이유는 대충 짐작이 가실테지만, 몇 가지 늘어놓아 보자면..
1. 너도 나도 할 말이 많은 요즘 핫 토픽, 핫 이슈 (카카오톡/텔레그렘 사태)
2. 그런데 정작 사실에 기반한 비판이나 평가보다는 ‘카더라’에 의존하는 현실 (수차례) 목격
3. 어느 정도 지식이 있어서 ‘설명’하지만 ‘틀린’ 지식 전파로 잘못된 정보 전달 사례 목격

물론 이 글을 쓰고 있는 저도 암호학쪽 전문가는 아닙니다만.. (…메신져 개발자는 더더욱 아니구요)
그냥 보고만 있기엔 답답해서 몇 글자 끄적여 볼까 합니다.

사실 사태(?)가 일어나고 나서 몇몇 분들께서 궁금해하시며 물어보셨는데, 마땅히 한글로 잘 설명된 자료도 없는것 같아 조금이나마 이해에 도움이 되었으면 하는 마음입니다.

이 글의 대상은 암호학/보안 전문가보다는 주위 친구, 가족 등의 ‘일반 유져‘를 위해 쓰여지는 글이므로 수학적인 내용은 최대한 간추려서 설명하도록 하겠습니다. (…친구나 가족이 보안전문가라면 orz..)

 

1. 사건(?) 발단

일단 E2E며 PFS며 설명하기 전에 앞서 왜 이런 이야기를 최근 사람들이 궁금해하고 떠드는지 알아야겠다 싶어 찾아봤다.

솔직히 처음엔 왠만해선 신경 안쓰려고 꽤나 노력했기 때문에 정확히 언제부터 시작된건지 왜 시작된건지 찾아봤는데, 체포한 사람 조사 과정에서 카카오톡 대화 내용을 조사했고 앞으로도 검열할 것이라는 등의 매우 정치적인 내용들이 얽히고 설켜있어서 더이상 따라가는건 포기 — 정치적 이슈 신경쓰는게 필자는 제일 귀찮고.. 이 글의 목적은 정치 얘기가 아닌 기술 설명이니까 넘어가도록 하자.

어찌됐든 뭐 마치 이제껏 몰랐다거나.. 카카오톡이 숨겨왔다거나.. 하는 뉘앙스로 우려하는 (혹은 까대는) 사람들이 급격히 늘어났다. 그 가운데 멀쩡히 잘 서비스하고 있던 카카오는 마른 하늘에 날벼락을 맞고 텔레그램의 급부상 시대를 맞이하게 된다.

KakaoTalk vs Telegram?

개인적으로 이번 일로 인해서 국민들의 프라이버시나 보안에 대한 경각심이 한층 더 높아지고, 걱정하기 시작하고, 신경쓰기 시작하고, 실제로 다른 메신져로 갈아타는 ‘행동’까지 보였다는데 대해서 나쁘지 않은 레슨이었다고 생각한다. 물론 이 때문에 고민이 많아진 사람들, 매일 밤새 부들부들하며 고생해야하는 사람들이 늘어나긴 했지만서도 :(

하튼, 많은 사람들이 걱정하고 비판하는 내용은 대충 이러하다:

  • 도/감청이 가능하지 않느냐?
  • 서버에 평문으로 저장되는 메세지들은 검열 대상이고 정부가 원하면 열람 가능하다
  • 서버에 저장하는 기간이 너무 긴것 아니냐?

실시간 도/감청에 대한 내용은 일전에 Man-in-the-middle (MITM-중간자 공격)을 설명하면서 언급했는데, 현재 카카오톡 같은 경우는 certificate pinning이라는 방법을 사용하고 있어서 제 3자가 폰이나 컴퓨터를 장악하지 않는 이상 통신 도청만으로는 개입하기 불가능에 가까운것이 사실이다. 법적으로 영장들고 가서 서버열람을 하면 (현재처럼 암호화가 되어있지 않은 상황에서는) 내용을 볼 수 있겠지만, 이건 법적 문제지 기술적 문제가 아니므로 논외 — 물론 이 마저도 불가능에 가깝게 만들 수 있다 (아래 E2EE 참조). 서버에 저장하는 기간에 대해서는 사실 기술적인 어려움보다는 보안성사용편의성 사이에서 밸런스를 조절해야하는 어려움이 크다. 저장 기간을 대폭 줄이면 당연히 보안적으로는 향상이 되겠지만, 사용자 입장에서는 그 시간내에 메세지 확인하지 못하면 서버에서 이미 삭제된 (읽지 못한) 메세지를 받을 수 없게되기 때문이다. 몇 달, 몇 일, 혹은 몇시간이 적당한 밸런스인지는 의견들이 분분하겠지만.. 모든 제품이나 서비스가 그렇듯이, 모두를 만족 시킬 수는 없고 ‘대부분’이 동의하는 타협점을 찾는것이 관건이라고 본다.

그럼 이제 정책 얘기는 그만하고 기술과 알고리즘에 대해서 이야기 해보자.
(EDIT: -_-.. 요즘 일이 바빠서 글을 몇일에 걸쳐서 작성했는데 그 사이에 다음카카오측에서 여러가지 파문을 일으킬만한 기자회견 등을 했다. 그와 관련된 내용들은 굳이 다루지 않겠고, 본글의 원래 목적이었던 기술 설명에 집중하도록 하자.)

 

2. End-to-End Encryption

보통 줄여서 E2EE 혹은 한국어로 종단간 암호화라고 불리는 이것은 무엇일까?

말 그대로 한 end-point에서 다른 end-point, 즉 메신져 문맥에서는 한 유져가 상대방 유져와 대화를 할 때 내용을 암호화하는 통신 패러다임이다. 여기서 중요한 것은, 각 end-point에 해당하는 유져들만이 이 암호화된 대화를 읽을 수 있어야한다는 점이다. 중간에 ‘서버’라고 불리는 중계자가 존재해도 말이다.

현재 카카오톡 메세지가 한 유져에서 상대방 유져에게 전송되는 통신 구간을 간단히 그림으로 표현하자면 다음과 같다.
(주의: 이 포스팅에 있는 내용은 이해를 돕기 위해 단순화 되었거나 이전 분석을 토대로 한 내용으로 현재 실제 구현과 다를 수 있습니다.)

그림 1. 현재 카카오톡 메세지 전달 통신 구조

글로 설명하자면, 일단 송신자의 클라이언트가 먼저 서버와 보안 통신에 필요한 AES 암호화 key를 공유한다. 이 handshake 부분은 현재 RSA 알고리즘을 이용하여 보호하는데, 쉽게 말해 위의 그림에서 점선으로 감싸진 부분은 클라이언트와 서버밖에 해독할 수 없다는 말이다. 그리고 나서는 세션이 파기되기 전까지는 서버와 공유한 이 AES key를 이용하여 메세지를 암호화하여 송/수신한다. 모든 통신을 RSA를 이용한 비대칭키 암호화를 사용해도 문제는 없지만 데이터 사용량과 CPU 사용률이 대칭키를 사용하는 것보다 비효율적이기 때문에, 이후 부터는 서로 공유한 (AES) symmetric key를 사용하는데, 이런 암호체계를 hybrid cryptosystem이라고 부른다.

위에서도 언급했듯이, 네트워크 스니핑을 통한 실시감 도/감청은 RSA가 부서지지 않는 이상 불가능하다. 즉, 서버/클라이언트간 통신 구간은 안전하다는 말이다.

지금 가장 크게 문제되는 것은 위의 그림에도 나와있듯이 어떤 기관 혹은 범죄 조직이 서버에 저장된 평문 메세지를 열람 가능해질때이다.

카카오톡의 프로토콜 구조상 클라이언트에서 암호화되어 서버로 전송된 메세지는 서버단에서 복호화된 뒤 저장되고, 메세지 수신자 클라이언트에게 전송할때 그 클라이언트와 약속한 key를 이용하여 암호화해서 전송한다. 여기서 사실 메세지가 서버에 복호화되서 저장되느냐, 암호화된 채로 저장되느냐는 큰 차이가 없다 — 서버에서 복호화 가능한 상태 라는것이 중요하다.

그렇다면, 서버가 해독할 수 없도록 하는 방식을 도입해야하는데 여기서 등장하는 개념이 End-to-End Encryption이다. P2P (peer-to-peer) 구조로 클라이언트간에 직접 연결하는 메신져 구조가 아닌 이상, 중간에서 메세지를 보관 및 릴레이 해주는 중계 서버가 필요하기 마련인데 그 서버를 믿을 수 없을 경우에 택하는 방식이다. 바로, 서버가 알지 못하는 key를 각 클라이언트들이 공유를 하고 그걸 이용해서 자신들의 메세지를 암호화해서 전송하면 서버 입장에서는 암호화된 무의미한 데이터만 보고 저장할 수 있을 뿐 딱히 할 수 있는게 없다 — 누군가 이 자료를 빼가거나 달라고 요청해서 내주어도 그게 서비스 운영자 입장에서 할 수 있는 전부라는것.

이를 위해서 열심히 작업했지만 뭔가 허접해보이는 그림을 또 한번 보자.

그림 2. End-to-End Encryption

흠.. 그림을 붙이고 보니 방금 설명한 내용 그대로라 딱히 무슨 부연설명이 필요할지 모르겠다…쿨럭

중요한 것은 각 클라이언트가 서로만이 알고 있는 비밀키를 가지고 암호화를 한다는 점이다.

물론 이 그림을 간략화 하면서 빠진 내용이 있는데, 메세지 내용은 암호화 하지만, 누군가에게 보내는지나 어느 시간에 보냈는지 등은 클라이언트만 알고 있는 키로 암호화하기 어렵다는 점이다. 서버가 해독할 수 있는 어느정도 메타데이터는 있어야 제대로 전송을 할 것 아닌가? 사실 이 문제는 또 다시 정책적인 문제 혹은 정의 (definition) 문제의 늪에 빠지게 만든다. 누가, 누구에게, 언제, 얼마나 많은 데이터를 보냈다는 내용은 서버가 제대로 된 서비스를 하기 위해서 필수로 알아야하는 (혹은 자연적으로 알게되는) 정보인데, 이것을 알고 있는것은 사생활 침해의 범주에 들어가는가, 아닌가? 등의 여러 문제를 야기하기 때문이다. 당연히 이 글에서는 논외 주제이므로 넘어가도록 한다 :p

이해력이 빠르고 예리한 독자들은 위의 문제보다 더 시급한 문제에 대한 궁금증이 생겼을 것이다: “다 좋은데.. 서버가 알 수 없도록 클라이언트간에 비밀키를 어떻게 공유하지?”

이 문제를 해결하기 위해서는 Diffie-Hellman Key Exchange (DH)라는 개념을 알아야한다. 비밀키 교환에 사용되는 이 방법은 Key Agreement 라고도 불리는데, 그 이유는 사용할 키를 실제로 ‘교환’하는것이 아니라 각자가 가진 정보로 ‘도출’해내는 방법이기 때문이다.

그림 그리는거에 재미들린 김에 하나 더 추가해보자면…

그림 3. Diffie-Hellman Key Exchange

그림이긴 그림인데, 수식이 들어가서 멘붕이 오는 사람들을 위해서 조금 더 풀어서 설명해보도록 하자.

일단 여기서 목적은 Alice와 Bob이 아무런 약속이나 미리 정해놓은 비밀 없이 비밀키인 s를 공유(라고 쓰고 ‘생성‘이라고 읽는다)하는 것이다. 하지만 이 둘의 대화를 엿듣고 있는 Eve도 있다는 점을 염두해두자.

모든 절차에 앞서 우선 Alice와 Bob은 비밀키 생성에 필요한 파라미터인 p와 g를 공유한다. 그리고 Alice와 Bob 각각 비밀 값인 a와 b를 선택한다. 그런 후에는,
1. Alice가 A (= ga mod p)를 계산하여 Bob에게 보낸다.
2. Bob이 B (= gb mod p)를 계산하여 Alice에게 보낸다.
3. Alice가 Bob에게 받은 B를 이용하여 s (= Ba mod p)를 계산한다.
4. Bob이 Alice에게 받은 A를 이용하여 s’ (= Ab mod p)를 계산한다.
5. 끝!

자, 중요한 부분을 짚어보자.

우선 굳이 1,2,3,4가 순차적으로 이루어질 필요는 없다. 예를 들어, 4번 스텝은 1번 스텝이 끝나자마자 이루어지고 동시에 2번 스텝을 실행할 수도 있다.

또한, 순서가 모두 끝난 후에 Alice와 Bob은 각각 s와 s’를 계산 가능한데, 풀어서 보면 s = Ba = (gb)= gba = gab = (ga)b = Ab = s’ 라는것을 쉽게 볼 수 있다. 즉, 서로 직접적인 비밀키를 전달하지 않고, 둘 다 똑같이 알고있는 값을 도출해내는데 성공한것이다.

하지만 이것보다 더 중요한 것은 공격자인 Eve가 어떤 정보를 볼 수 있었고 그걸로 도출해낼 수 있는 정보가 무엇이 있는지이다.

처음에 Alice와 Bob이 공유한 p, g는 물론 중간에 통신에서 전달된 A와 B 또한 습득가능한 Eve는 무얼 할 수 있을까.
결론부터 말하자면, 현재 기술과 알고리즘으로는 그닥 할 수 있는게 없다.
물론.. 무조건 성립되는것은 아니다. 그냥 아무렇지 않게 지나친 p와 g, modulo arithmetic, 그리고 exponentiation 등을 잘 이해하고 적당한 값을 사용해야만 비로소 ‘안전한’ 알고리즘이 되기 때문이다.

이 글에서는 자세한 수학적 증명이나 개념 설명에 들어가진 않겠지만, 관심이 있다면 다음 관련 키워드를 찾아보는 것을 추천한다: multiplicative group of integers modulo n, primitive root modulo n, Diffie-Hellman problem, discrete logarithm problem 등.

간략히 설명하자면, <p, g, A, B>를 가지고 s를 계산하려면 a나 b를 알아내거나 (discrete log problem) ga와 gb를 이용하여 gab를 계산할 수 있어야 하는데 (diffie-hellman problem) 두 가지 모두 효율적인 시간복잡도를 가진 풀이법이 발견되지 않았기 때문에, Eve가 통신을 엿들어도 그다지 할 수 있는것이 없다는 것이다.

한가지 유의해야할 점은 DH 알고리즘은 authenticity, 즉 지금 통신 중인 상대방이 정말 내가 생각하는 그 상대방이 맞는지에 대해서는 아무런 도움을 주지 못한다는 점이다. 다른 말로, MITM (중간자) 공격에 취약하기 때문에, 무언가 다른 방법으로 서로 ‘인증’ 절차를 먼저 거쳐야한다는 것이다. 이 부분에 대해서는 여러가지 방법이 있지만, 카카오톡과 같은 상황에서는 현재 방식처럼 유져 고유 키 + RSA를 이용하여 서버가 각 클라이언트를 인증해주면 되기 때문에, 큰 문제는 아니다 — 서버는 그림상에서 Eve의 위치에서 얻을 수 있는 정보를 동일하게 얻을 수 있지만 중계를 해주는 역할이다.

이렇게 해서, 두 유져가 비밀키를 서버는 알 수 없도록 공유하고 나서는 그림 2에서처럼 단말기에서 암호화를 한 뒤 서버에 보내는 구조로 통신하면 된다. 서버가 저장하고 볼 수 있는 내용은 (복호화할 수 있는 키 없이) 암호화된 데이터이기 때문에 서버 열람을 통해 메세지 내용이 유출되거나 검열될 가능성이 없어진다.

 

3. Perfect Forward Secrecy

종단간 암호화는 많이들 얘기하는데다가 이름 자체에 이미 설명이 있는거나 다름없기 때문에 대중들이 조금 더 잘 이해하는 반면, forward secrecy 혹은 PFS 라고 불리는 이 녀석에 대해선 말이 나오지만 정확히 뭔지 모르는 사람들이 많다.

예전에 카카오톡 프로토콜 분석 관련글을 작성할때 잠깐 언급했었듯이, 현재 카카오톡 구조는 Perfect Forward Secrecy 라는 보안 특성을 지원하지 않는다.

그래서… 요즘 언론 매체든 페이스북이든 트위터든 어디서든 회자되고 있는 이녀석의 정체는 무엇일까.

 

우선, 클라이언트와 서버 사이에 통신할때 쓰였던 서버 private key가 유출되었다고 가정해보자. 엄청난 대사고가 아닐 수 없다.

이번 역시 그림으로 시작하자, 후훗.

그림 4. Non-PFS 시스템에서의 문제

그림 4의 윗부분은 아까 그림 1에서 본 것과 같다. 즉, 현재 RSA를 사용하여 AES 키를 공유하는 상황이다.

이런 설정에서 공격자 (혹은 검열자)가 클라이언트/서버 간의 통신내용을 저장한다. 물론, 이 내용만 가지고는 RSA를 부실 수 있지 않은 이상 내용을 복호화 할 수 없다. 하지만, 유출된 private key가 존재한다면 저장해둔 이전 클라/서버간의 대화에서 (특히, handshake 부분) AES 키를 복호화해 추출해낼 수 있다. 이 AES key로 그 키를 이용하여 암호화된 메세지들 모두 해독해 볼 수 있다.

여기서 심각한 점은, 앞으로의 메세지들 뿐만이 아니라 이전에 저장해둔 (암호화 되어있던) 메세지들도 풀 수 있다는 점이다. 서버에 저장되있는 메세지는 물론이고, 서버에서 삭제되었다고 해도 이전에 이미 암호화된 통신 내용을 저장해놓았다면 다시 돌아가서 복호화해볼 수 있게 된 셈이다.

Forward Secrecy는 ‘long-term key’ (e.g. RSA pub/priv key)를 통해 만들어지거나 보호된 ‘session key’ (e.g. AES key)들이 long-term key가 유출된 이후에도 복호화되는 위협을 받지 않는다는 암호학적 성질을 나타낸다.

그럼 어떻게 하면 이 성질을 탑재(?)한 시스템을 만들 수 있을까?

유용하게도, 우리가 좀전에 살펴봤던 Diffie-Hellman Key Exchange 알고리즘 자체가 PFS 성질 또한 자동적으로 지원한다. 즉, DH를 사용하므로써 E2EE와 PFS라는 두마리의 토끼를 동시에 잡을 수 있는 것이다.

그림 5. DH를 이용한 E2EE/PFS 시스템

위의 그림으로 전체적인 시스템을 살펴보자.

먼저 각 클라이언트가 DH key exchange에 사용할 g, p 파라미터를 교환한 뒤 (스텝 1-2), 그림 3에서 설명한것 처럼 DH를 이용하여 shared 비밀키를 만든다 (스텝 3-8). 여기까지 성공적으로 마쳤다면, 클라이언트는 서버가 알지 못하는  비밀키를 가지고 있으니 이것으로 메세지들을 암호화하여 주고 받으면 된다 (스텝 9-10).

서버 검열을 통해서든지, 네트워크 스니핑을 통해서든지 클라이언트/서버간의 통신 내용을 열람 할 수 있어도 앞서 설명한 이유들 때문에 크게 할 수 있는것이나 알 수 있는 것이 없다.

이마저도 RSA 등을 통해 암호화된 채널로 서버와 클라이언트간에 통신하므로 네트워크상에서 제 3자가 보기에는 지금처럼 그냥 랜덤한 바이트들이 오고가는 정도이다. 하지만, 누군가의 압박으로 혹은 해킹과 같은 보안 사고 때문에 서버 내용 열람이나 private key 유출이 된 시나리오라고 할 지라도 메세지 내용을 복호화하는 것이 불가능에 가깝게 되었다.

 

여기서 조금 더 발전시키자면, DH 단계에서 도출하는 key를 필요한 일이 끝나면 파기시키고 필요할때 다시 새로운 key를 만드는 Ephemeral Diffie-Hellman (EDH)를 사용하면 더 확실한 PFS 특성을 가질 수 있다. 한 번 생성된 shared key를 계속 쓰게되면 그 key가 어쩌다가 유출되면 역시 마찬가지로 그 키로 암호화된 메세지들을 모두 복호화할 수 있기 때문이다. 물론 구조상 그 키를 추출하는것은 실제 단말기를 손에 넣어서 (혹은 remote exploit 등으로) 하는 방법 밖에 없겠지만 수시로 필요에 따라 기존 shared key를 파기하고 새로운 key를 생성해낼 수 있는 유연성을 가진 시스템을 설계하는것이 보안상 좋다 — 예를들어 TLS, SSH, OTR 프로토콜 같은 경우에는 세션마다 새로운 ephemeral key를 만들어 사용한다.

이에 따른 사용편의성 감소는 불가피하게 발생한다. 아마 현실적으로 구현될때는 (적어도 메신져앱에서는) ephemeral이 아닌 보통 DH로 key agreement를 하지 않을까 싶다 — 어짜피 단말기가 털리면 답이 없기 때문이다.

 

4. Fact? 현실?

자, 이제 어느정도 이해가 되었으리라 생각하고..
(아직도 뭔말인지 모르겠다면 새벽마다 글을 횡설수설 나누어 쓴 제 잘못입니다 ㅜㅜ 댓글로 질문 남겨주세요!)

소위 ‘전문가’들이 주장하는 부분들에 대해서 한두가지만 짚고 넘어가보자.
따로 직접 물어보고 답변을 얻은것들이 아니고, 언론 매체에서 인터뷰한 내용을 바탕으로 작성한 것이니 유념하기 바란다.

 

첫째. 그룹채팅 (3인 이상) 내용 E2E 암호화도 별로 어렵지 않다. (기사)

뭐, 이건 누구 관점에서 어떻게 보느냐에 따라서 천차만별일 수 있는 내용이다. 언뜻보기엔 E2EE를 멀티파티로 옮기는 것은 그리 어렵지 않아보일 수도 있다.

‘두 명이서만 교환하던 키를 이제 N명이서 교환하면 되는것 아닌가? 뭐가 어렵지?’ 라는 생각이 들 수 있지만, group key distribution 문제는 아주 간단하진 않다. 여전히 서버는 모르도록 유지하면서 참여중인 클라이언트들은 모두 같은 값을 도출해낼 수 있어야하기 때문이다. 사실 이 부분에 있어서 DH이 다시한번 구세주로 떠오를 수 있는데, 자연적으로 여러명과 key agreement를 할 수 있도록 해주기 때문이다. 물론 과정 자체는 두 명이서 교환하던것보다는 조금 더 복잡해진다. 특정 순서로 exponentiation을 해야하는데, 최적화된 순서를 사용하면 각 클라이언트가 총 log2(N) + 1 번만큼 modular exponentiation을 해서 N명이 사용할 수 있는 shared 키를 도출 할 수 있다.

솔직히 딱 N명만 상대로 하는 키 공유는 기술적으로 어렵지 않다. 이 문제가 어려워지기 시작하는 것은 정책 결정에 따른다. 즉, 어느정도까지 보안성을 지키고 싶으냐에 따라 달라진다는 말이다. 다음 예제를 생각해보자.

예를 들어, 처음에 대화방을 만들어 N명이 대화를 시작했는데, 중간에 한 명이 나갔다. 그럼 어떻게 해야할까? 그냥 생각하면 큰 문제가 아닐것 같지만, 이때 N-1 명의 멤버들이 새로운 shared key를 생성하여 공유하지 않는다면 그 나간 사람이 대화방을 나간 이후의 대화를 볼 수 없어야함에도 불구하고 (암호화된 이후 내용 패킷들을 구했다고 했을때) 그룹 대화방을 만들때 공유된 키를 사용하여 복호화해서 대화방 나간 이후의 내용도 읽을 수 있게 되는것이다.

아하. 그러면 누군가가 대화방을 나가면 shared key를 변경하면 되겠네? 라고 생각들겠지만.. 이것도 기술적으론 쉽지만 사용편의면에서 문제가 생긴다. 그 사람이 나가기 전에 보냈던 메세지들을 모든 참여자가 읽었으면 큰 상관이 없지만, 아직 읽지 않은 참여자가 있는데 shared key를 변경해버리면 그 이전 메세지들을 더이상 복호화할 수 없게 되기 때문이다. 또한, 모든 참여자가 새로운 key를 도출해내기 전에는 메세지를 보낼 수 없게 된다. (새로운 참여자가 추가되도 비슷한 문제점들이 생긴다.)

이러하듯, 어디에 선을 긋느냐에 따라서 생각할 범주가 확 변하고, 시스템 설계도 구현 방법도 달라지게 된다. 그래서 어려운거다.

 

둘째. 텔레그램 같은 경우, 내부적으로 자체 개발한 암호화 알고리즘을 사용하므로 공격하기가 더 까다롭다.

전형적인 ‘security through obscurity’ 전략. 근데 텔레그램을 분석해본적이 없기 때문에 섣불리 이렇다 저렇다 할 수는 없지만, 웹사이트에 설명되어있는 내용들을 보면 꽤나 많이 생각했다는걸 알 수 있고 실제로 보안에 신경쓰고 더 향상시키기 위해 노력하겠다는 점 정도는 확실히 보인달까. 일전에 있었던 암호화된 메세지 툭 던져주고 ‘해킹해봐라’ 라는 식의 ‘대회’.. 또는 ‘우리 팀에는 수학 PhD들이 많아서 알고리즘은 확실하다’ 라는 등의 주장은 개인적으로 제일 싫어하는 형태의 PR인데, 누구의 말마따나 이들은 수학자일지 몰라도 보안 전문가는 아니라는 점이다. 이론만으로 완전한 보안을 성취하기는 어렵다. 자체 개발 혹은 변경한 루틴이 있다면 분석하고 공격하기에 더 많은 시간과 노력이 필요하다는것은 당연지사.

그렇다고 해도, 인정할건 인정해야하지 않겠는가. 일단 유져의 프라이버시를 위한 최소한의 구현들은 해놓았다는 사실과 똑똑한 수학자들을 팀원으로 데리고 있는것이 해가 되지는 않았을것이라는 생각이다. 무엇보다 스펙 및 API 공개를 통한 확장성 또한 고려했다는 점에서 꽤나 오픈된 메신져 플랫폼을 제공한다는 점  또한 플러스.

 

셋째. E2EE를 구현하는데 왜 모바일과 PC 버젼 동시 지원을 안하나?

기사에서 본건지.. 페이스북에서 본건지 잘 기억이 안나는데.. 최근에 다음카카오 기자회견에서 앞으로의 각 분기 계획에 대해서 누군가가 한 질문이었던것 같다.

내가 읽기로는 E2E 지원을 모바일과 PC버젼에서 시기적으로 동시에 지원하지 않는것에 대한 의문보다는.. 어떤 사람 A가 B와 시크릿모드로 모바일을 통해 대화를 하고 있었다면 컴퓨터로 옮겨와서도 B와 하던 시크릿대화를 이어갈 수 있어야 한다고 생각하고 질문한것 같은 느낌을 받았다.

만약 이게 사실이라면, 그 사람이 언젠가 이 글을 읽고 E2E에 대한 이해를 하길 바란다. End-to-end는 말 그대로 한 엔드포인트에서 다른 엔드포인트 간의 연결을 뜻한다.

모바일 단말기와 컴퓨터는 다른 엔드포인트이고.. 당연히 서로 연속성을 지녀서 안되는게 정상이다. 이걸 가능케 하려면 password-derived 형식으로 key를 만들어내야하는데, 이건 이거대로 대재앙.

 

5. 마치며…

뭔가 ‘간단하게 초등학생도 이해할 수 있을 정도의 레벨로 글을 써야겠다’라고 마음먹고 시작했던 글이었는데, 본의아니게 길어지고 복잡해졌다.. 뭔가 초보용도 고급용도 아닌 어중간한 느낌이라 살짝 찝찝하지만 누군가에겐 도움이 되리라 생각하고 끄적인다..

어떻게 보면 메신져에서 유져의 안전과 프라이버시를 지키기 위해 가장 기본이 되어야할 요소들임에도 불구하고 최근 사태가 터지기 전까지 아무도 관심을 가지지 않았었고 잘 알지도 못했던 주제인지라, 서론에서 말했듯이 이 주제들이 각광받고 사람들이 신경쓴다는 사실만으로도 감개무량하다. 이로인해 국민들이 보안에 대해 항상 신경쓰고 더 나아가 그 내부 구조까지 다는 아니더라도 어느정도 상식은 갖길 바라는 마음이다.

암호화 쪽에 겨냥한 포스팅이었지만, 그렇다고 공격 표면이 암호화에만 존재하는것은 아니다. 다른 로직 버그라던가 메모리 코럽션 버그등은 여전히 일어날 가능성이 있고 이런 류의 버그는 어떤면에서는 암호학적 공격보다 더 치명적일 수 있다. 한쪽에만 치우치지 않고 이번 기회로 전체적인 아키텍쳐, 시스템, 구현 등을 돌아보고 없는 것은 추가하고 있는것은 더욱 견고히 하는 작업을 통해 발전할 수 있지 않을까 한다.

 

지금 내가 아는 바로는 카카오 엔지니어들은 이미 종단간 암호화 지원을 위한 구현을 시작한지 조금 되었다. (이전에 공개된 사과문 + 최근 있었던 기자회견 등에서 이 계획이 진행중에 있음을 공표했다.)

‘외양간’ 프로젝트라는데, 진지함이 없다고 욕하는 사람들도 많이 봤지만.. 다음 소를 위해 허술한 외양간을 뜯어고친다는게 어디인가.

개인적인 생각으로는 이번 사태의 최대 피해자는 근면성실히 일하는 개발자들이다. 적어도 내가 아는 분들만 해도 자나깨나 보안에 신경쓰고 계신분들이고 실제로 이해도도 높으시고 구현도 잘 하시는 분들이다. 게다가 더 존경스러운것은 이미 잘 아심에도 불구하고 굳이 다른 분들의 의견을 묻고 토론하며 더 배우시려는 분들이 많다. 다음카카오 PR의 대실패로 인해 괜한 개발자들만 고생하는게 마음이 안쓰럽다. 그래도 지금이나마 최대한 빠르게 유져들의 프라이버시를 위해 달리는 분들에게 감사를 표한다. 보안쪽 특히 암호쪽은 서둘러 해서 좋을게 전혀 없는 분야다. 차근차근 정확히 이해하고 확실하게 구현해야 나중에 탈이 없다. 옆에서 유언비어로 뭐라고 떠들어대든 엔지니어의 자존심을 걸고 꿋꿋하게 좋은 결과를 내주시길 바라며..

요즘 핫이슈인 E2EE와 PFS에 대한 설명을 마치겠다!

 

긴 글 읽어주시느라 고생 많으셨습니다. 혹시라도 놓친 부분이나 실수한 부분이 있다면 댓글이나 이메일을 통해 알려주시면 수정하도록 하겠습니다. 따로 더 궁금한 점도 댓글로 남겨주시면 기회될때마다 답변 달도록 하겠습니다.

 

You may also like...

33 Responses

  1. Seungjoo Kim says:

    I love it!! 역쉬 문무를 겸비한 해커얌!! ^^b

  2. daehee says:

    좋은 포스팅입니다! :)

  3. Changgi Song says:

    감사합니다. 이해하는데 많은 도움이 되었습니다. ~! 특히 그림은 한눈에 이해되도록 잘 표현되었다고 생각합니다.! 추가적으로 종단간 암호를 풀때 걸리는 예상 소요시간 그래프를 여러가지 암호기법과 비교해서 그래프로 표현해서 올려주시면 이해하는데 더 잘 될 것 같습니다. 늦은 시간에 고생하셨습니다.~!

    • Cai says:

      제가 미적감각은 영 없어서 걱정했는데 ^^; 이해에 도움이 되셨다니 다행이고 칭찬해주셔서 감사합니다. 말씀하신 그래프가 추가되면 더 좋을것 같네요. 시간이 나면 정리해서 업데이트하던가 하겠습니다. 조언 감사드립니다.

  4. Jongmoon Lee says:

    좋은 포스팅 감사합니다. 글도 쉽게 잘 쓰시는 재주가 있으시군요!!^^

  5. Tamm says:

    좋은 글 감사합니다.

  6. heavensonic says:

    E2e든 pfs든,
    카카오톡이 법적인 이유로 감청에 응했을 때,
    서버 앞단에 mitm 장비를 설치하고 있을 경우는 사실 다 소용이 없지않나요? 클라이언트에서 클라이언트로 바로 통신이 이루어지는 p2p 구조도 아닌지라, 결국 서버를 거쳐가게 되면 클라이언트 클라이언트간의 Shared key도 가로 챌 수 있고 certificate pinning 이야 국가 입장에서 진짜 인증서 하나 찍어내는건 일도 아니니까요

    일반적 해킹의 관점에서는 뚫기 어려워 지나
    이번 카카오톡 문제처럼 업체의 협조하에 가능하냐? 불가능 하냐? 라고 따지면 가능하냐가 맞지 않는지요?

    • Cai says:

      E2E의 요점은 바로 서버나 혹은 다른 중간자가 공격을 시도해도 메세지를 읽어낼 수 없다는데 있습니다.
      글에서 언급된 RSA에 쓰이는 pub/priv key + cert 같은 경우는 말씀하신대로 국가단에서 개입하면 유져입장에선 딱히 막을 방법이 없습니다. 하지만 DH 같은 키 공유 방식을 통해서 클라이언트 키를 생성하게 되면 중간에서 장비를 설치하여 감청한다하여도 얻을 수 있는것이 없습니다.
      다만, 이러한 보안성은 카카오톡 서버가 적어도 ‘서비스’ 자체를 정직하게 한다는 가정하에 있습니다 — 즉, 유져들을 인증하고 유져 A가 B에게 메세지를 보내고 싶어할때 정말로 B와 메세지 교환을 하도록 해준다는 전제라는 것이죠. 만약 카카오 서버에서 임의로 (passive하게 보기만 하는것이 아닌) C 라는 중간자를 만들어서 마치 A가 B와 대화하고 있는것처럼, 그리고 B는 C를 거쳐 대화하지만 A와 대화하는것처럼 보이게 하는 active한 공격을 한다면 유져입장에선 DH를 써도 어쩔 도리가 없습니다 (글에서 언급한것처럼 DH 자체는 authenticity를 보장해주지 않기 때문이죠).

      그래서 이런 경우가 걱정된다면, 각 클라간에 정말로 자신이 대화하려는 상대와 대화를 하고 있다는 (서버가 관여할 수 없는) out-of-channel 인증절차가 필요하게 됩니다. 방법은 여러가지 있겠지만, 각 클라이언트별로 RSA keypair/cert을 만들어서 인증하는 방식이 그 중 하나입니다. 이렇게 되면 카카오 서버는 거의 정말 중계서버에 가깝게만 되는거죠. 중간에 MITM 공격을 passive하게 하면 얻는게 없고, active하게 하면 발각될 수 밖에 없으니까요 :)

      • heavensonic says:

        답변 감사합니다.

        현상황처럼 국가적 차원과
        기업의 협조적 상황에서의

        Mitm (말씀하신 내용처럼 중간자 c를 경유하는) 상황은 현재의 카카오톡 서버 구성으로썬 피할 수 없는 현실이라고 봅니다.

        단순히 e2e나 pfs를 도입한다고 해서 완전히 어떠한 방법으로든 안전해질꺼라고 믿는 대중들이 많기에
        댓글을 달아봤습니다. E2e나 pfs만 도입한다고 끝이라기 보다 국가적 차원의 개입과 업체의 협조를 어떻게 막을 것이고 그것을 어떻게 검증할 것이고 key pair /cert를 카카오톡 같은 몇천만 단위의 유저를.가진 메신저에서 싷질적으로 가능한지 … 등 궁금한게 많네요

        • Cai says:

          네, 말씀하신것에 적극 동의합니다.
          이 글의 목적은 e2e나 pfs를 도입하면 ‘끝’이다 보다는 아직 각각 개념을 잘 이해 못한 분들을 위해 설명하는 글에 가깝습니다.
          분명 어려운 문제임은 확실합니다. 그래도 일단 좋은 시작이니 응원할 뿐이죠.
          많은 사람들이 다같이 기술적으로, 그리고 정책적으로 고민해보아야 할 부분인것 같습니다.
          좋은 의견 감사합니다.

      • sonnet says:

        ” 카카오톡 서버가 적어도 ‘서비스’ 자체를 정직하게 한다는 가정”
        => 솔직히 이런 가정이 붙기 시작하면 e2e를 한 목적이 무색해지는 거고 그냥 안전하지 않은 시스템인 거죠.

  7. heavensonic says:

    제가 쓴 댓글 삭제 하셨는데
    왜 그러신건지 연유가 궁금합니다.

    원문
    ———————–

    E2e든 pfs든,
    카카오톡이 법적인 이유로 감청에 응했을 때,
    서버 앞단에 mitm 장비를 설치하고 있을 경우는 사실 다 소용이 없지않나요? 클라이언트에서 클라이언트로 바로 통신이 이루어지는 p2p 구조도 아닌지라, 결국 서버를 거쳐가게 되면 클라이언트 클라이언트간의 Shared key도 가로 챌 수 있고 certificate pinning 이야 국가 입장에서 진짜 인증서 하나 찍어내는건 일도 아니니까요

    일반적 해킹의 관점에서는 뚫기 어려워 지나
    이번 카카오톡 문제처럼 업체의 협조하에 가능하냐? 불가능 하냐? 라고 따지면 가능하냐가 맞지 않는지요?

    • Cai says:

      삭제가 아니고 스팸 때문에 approval을 해야만 뜨게 되어있습니다 ^^;
      혼란을 드려 죄송합니다. 위에 보시면 답글도 달았습니다.

  8. Seungmin Shin says:

    안녕하세요. 좋은 글 감사합니다.
    저는 게임 보안 분야에서 일하는데 이번 KGC 2014 (http://www.kgconf.com) 에서 제가 강연하는 내용의 일부로 소개하고 싶어서 문의 드립니다.

    • Cai says:

      네 어떤 질문이 있으신가요? 제 이메일로 메일 주시면 감사하겠습니다.

      • Seungmin Shin says:

        Email 주소가 About 에는 이렇게 나와서요.
        “E-mail: bria…@gmail.com”
        제 메일 주소는 기록해 두었는데 연락 주시겠습니까?

        내용은 질문 보다는 작성하신 블로그의 내용을 KGC 2014에서 소개하는 내용입니다.
        게임 보안의 암호화에 대하여 강연을 하는데 카톡의 경우 본 블로그 내용을 인용하였으면 합니다. 다른 분들도 들어 와서 보면 좋겠다고 생각했습니다.

        • Cai says:

          아하 … 을 클릭하시면 캡챠 인증 이후에 보실 수 있어요! (스팸 때문에 ㅎㅎ)
          출처만 밝혀주시면 인용하시는것은 마음껏 하셔도 됩니다. 소개해주시면 저야 감사하죠 :)

          • Seungmin Shin says:

            흔쾌히 말씀해 주셔서 감사합니다.
            발표 후 SlideShare 에 올리고 나서 다시 연락 드리겠습니다.
            메일 잘 받았습니다. ;-)

  9. BK says:

    좋은 내용 잘 보고 갑니다. 사실 중간에 조금 복잡해진 시점에서는 제대로 이해를 못한 것 같습니다만….
    저는 대충 의도하신 바를 이해했다는 정도로 만족해야 할 것 같습니다.
    감사합니다.

  10. 청향 says:

    정말 그림으로 이렇게 이해가 잘 되는건 처음인것 같습니다. ㅎㅎ
    좋은 글 감사드립니다. ^^/

  11. Dan says:

    You are the best Cai. This explanation was so much helpful. One day I hope I can be like you ….

  12. AmesianX says:

    텔레그램의 경우, 정상적인 통신패킷을 몇회에 걸쳐서 다 저장해놓은 뒤에 리플레이 시키면서 계산을 통해
    암호화를 크랙할 수 있는 구조가 아닙니다. 사람들은 이점에서 혼돈을 할 수도 있는데, MITM 을 사용하는 것은
    실시간레벨입니다. 텔레그램의 DH 를 해킹할려면 최소한 텔레그램측이 언급한 세션이 살아있는 시간동안에
    8 바이트를 맞춰서 크랙을 시켜야 성공할 수 있습니다. 이 내용은 모 해커의 친구라고 알려진 알렉스라는 사람이
    언급한 2의 64승 크랙 문서에 보시면 잘 이해하실 수 있으실 겁니다. 사실, 텔레그램측이 낸 컨테스트의 경우에
    이들이 풀지못하게 할려는 의도는 없었습니다. 아마도 이들은 풀릴수도 있을 것이라고 생각했을 것 같습니다.
    왜냐면, 원래 키교환 체크 부분이 8 바이트 비교가 원래 텔레그램 클라이언트 구현인데 이 길이를 4바이트로 줄여
    놓았다고 언급되어 있습니다. 물론, 이정도로 친절하게 적어주진 않았죠. 눈치를 채라는 것이었겠죠? 8 바이트가
    원래 비교해야할 해쉬의 핑거프린트 값인데 분명 컨테스트 메인에 4 바이트이다라고 못박아 놨는데 이걸 눈치채지
    못할 사람이 몇명이나 있었을까요? 전 눈치는 챘습니다만 4 바이트도 사실 어마무시한 값이긴 합니다. 그런데,
    알렉스 문서만 봤다면 알렉스 문서는 실 클라이언트 기준으로 작성되어 있어서 2의 64 승 크랙문제라고 적어
    놓은거 같습니다. 실시간 세션에서 세션종료타임 전까지 2의 32승만 맞춰내면 되는 문제였던거 같습니다. 그래서
    만약 어떤 인간들이 미쳐갖고는 하드웨어까지 다 동원해서 시간안에 32승을 맞춰내면 상금줄려고 그런 대회를
    열은거 같았더란 그런 눈치를 깠었더랬져.. 물론, 제가 분석한 모든 내용은 저 혼자 분석한 것인데 프로젝트를 구성
    하겠다며 사람을 모은 친구들이 알고봤더니 모의해킹 수준 레벨밖에는 시야가 없는 사람들이더군요. 심지어 모의
    해킹 레벨 시야조차도 제대로 갖춘 친구는 프로젝트 팀의 에이스라는 나이어린 친구 한명밖에는 없더군요. 그런데
    텔레그램에 도전장을 낸걸 보고는 제가 기특(?)해보여서 다 분석을 해줬었드랬죠. 분석 다 해주니까 선배님선배님
    그러고 쫄쫄 따라다니는 그런 모양새가 되었는데 따끔하게(?) 혼을 좀 내줬드랬습니다. 왜냐면, 뻔히 암호화 크랙
    컨테스트라고 적혀있는데도 불구하고 모의해킹 레벨수준에서 제대로 프로그래밍도 주문대로 짜지도 못하는 그런
    상태에서 도전한걸 지적해주었죠. 물론, 도전 자체는 칭찬을 해주었으나 텔레그램측에 대고 망언을 쏟아내길래
    그것도 발견한 취약점이라면서 막 대박이라는 표현을 쓰면서 그런 망언을 쏟아내길래 나중에 좀 따끔히 말을 해주
    었드랬었습니다. 그들이 발견했다는 취약점도 제가 봤을때는 취약점이 아니었거든요.. 여튼, 그럼에도 불구하고 그
    주도한 자가 언론에 힘을 미칠수 있는 사람이 한명 있었기 때문에 언론플레이를 하더군요. 텔레그램 취약하다 뭐
    이런식의 기사를 포털에 내는 것을 보고 참 개인적으로 한국을 걱정할 수 밖에 없게되었드랬습니다. 언론 플레이를
    할려면 제대로 해야되는데 기껏해야 모의해킹 수준레벨을 현실 익스플로잇 수준도 아니고 암호학크랙이 필요한
    분야에 갖다붙여서 언론질을 하니 얼마나 개인적으로 답답했겠습니까? 그것도 어린 친구들이 말입니다. 이제 갓
    대학생 나이정도의 아이들인데 말입니다. 프로그래밍도 몰라서 개발자로 한 몇년은 현업에서 좀 굴러먹어야 할것
    같은 친구들이 그런짓을 하는거보고 시중에 책이 많이 나오긴 나왔구나라는 생각이 들더군요.. 끽해야 안드로이드
    디컴팔해서 내부 보고 DB 값 보고 그런짓이나 좀 할 줄 아는 수준으로 텔레그램 까서 취약점 찾겠다면서, 도전한
    분야가 텔레그램 암호화 크랙 컨테스트라니.. 그나마 저도 분석은 다 할줄 알아도 수학적 기반이 전문한지라 감히
    크랙하겠다는 생각은 못하는데 말입니다. 죽기전에 신의 은총빨이 떨어져서 정신히 헷가닥 한번 한다면, 암호화는
    아니고 시스템적인 취약점(랜덤함수 취약점으로 기존에 텔레그램에 취약점이 나왔었음)을 노릴 수 있는 그런 운이
    생긴다면 모르겠습니다. 여튼, 상황들 돌아가는 것 보면 정말 가관입니다.
    저는 개인적으로 이런 생각을 합니다.
    해커면 정석에 도전하고 싶을때는 정석을 알아야하고 정석위에 서있어야 한다. 그렇지 못하다면 시스템 레벨에서의
    접근을 찾아라. 라고 말입니다. 저만 이런말을 할까요?
    알렉스 문서에 보면 거기에도 그런 비슷한 뉘앙스가 적혀있었죠. 텔레그램을 정상적으로 정석적 공략으로 크랙하느니
    그냥 악성코드 설치하게 해서 노리겠다라고 말입니다. 그게 훨씬 효율적이고 가능성도 높다라는 뉘앙스로 적혀있더군요.
    제발 정석이 뭐고 시스템적인 트릭이 뭐고 이론이 뭔지, 좀 이런 분간을 제대로할 줄 알면 좋겠다는 생각을 한게 이 바닥
    십수년 동안 경험하면서 느낀겁니다. 실력은 이론 개주라고 그러고 정석도 모르며 기껏해야 약간 시스템적인 트릭을 부릴
    줄 알면서, 심지어는 개발이나 프로그래밍에 취미도 없으면서, 최소한 텔레그램 암호화 컨테스트 같은걸 도전할때는 뭔가
    경건함 마음 정도는 있어야할텐데, 취약점도 아닌걸 취약점이라고 발견해놓고 “이 텔레그램 놈들 이놈들도 별거 아니야”
    라는 식으로 막말을 하는걸 보면 무슨 생각이 들었겠습니까.. 그런 자세를 갖고 있는 사람들이 언론플레이는 쩔더군요..
    그래서 제가 혼구멍을 내줬더니 찌그러지더군요.. 근데, 어떤 사람은 이렇게 치명적으로 지적질해주면 극복하는 사람이
    있겠지만 제가 여태본 대부분의 “키워볼려고 했던” 사람들은 이렇게 밟아주면 다 거기서 손을 놓습디다.. 요즘 제 주변에는
    부동산으로 자신의 관심사를 전향한 사람들이 2명이나 되고 1명은 부동산 얘기를 해야 제 말을 받아주었드랬죠.
    한때 컴퓨터에 미쳐있었던 사람들이 저한테 오면 제초제를 맞아서 다 죽어버립디다. 전 정석대로 말해주었을 뿐인데
    나중에 가면 술먹으면서 제가 기술얘기를 하면 허공을 보는 단계가 되죠. 멘탈이 다 죽어버리니까..
    기본기가 없으면 기본기부터 해야되는데.. 요즘은 기본기부터 하는게 아니라 건성건성이 너무 많아서 탈인거 같습니다.
    언론플레이도 좋지만 정석부터 밟아가려는 자세가 있으면 좋겠습니다. 컴퓨터 배운게 언론플레이 할려고 배운게 아니라
    그냥 재밌고 호기심이 생기니까 궁금해서 알고싶어서 한 것일텐데.. 궁금해서 배웠다면서 대회나 버그헌팅에 열을 올리고..
    시스템과 과학에 대한 호기심이 있었던게 아니라 잿밥에 관심이 많았던건지.. 그래서 정석을 얘기하면 눈을 피하고 절망
    하다가 부동산에나 빠지고.. 이젠 제 주위에 단 한명도 컴퓨터에 빠져있는 미친놈이 없네요.. 그러다보니 저도 사는 낙이
    없어져갑니다.. 개발자들은 너무 몰라서 탈이고.. 해커들은 너무 비정상적인 시야를 갖고 있는 사람들이 많아서 탈이고..
    그나마 말이 통할만한 사람들은 전부 해외로 나가고.. 그런거겠죠.. ㅎㅎ 모 해커군도 해외나갈 채비를 하고 있다는 소문이
    들리는거보면.. 쩝. 씨가 마르는군요..

  13. jangmin says:

    잘 읽었습니다. 좋은글 감사합니다.

  14. Newface says:

    wire라는 메신저 서비스를 보고 있는데, 이 메신저 서비스의 보안 수준에 대해 평가를 부탁드려도 될까요?
    비교 대상 메신저는 텔레그램, 시그널 등등

Leave a Reply to jangmin Cancel reply

Your email address will not be published. Required fields are marked *