그것이 알고싶다 – 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...

32 Responses

  1. minji says:

    좋은글 잘읽고갑니다! ^0^

  2. Woojin Lee says:

    좋은글 감사합니다. 새해복 많이 받으세요

Leave a Reply

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