kentakang

종단간 암호화가 대체 뭔데

2024. 02. 17

컴퓨터 보안에 대해 완전히 무지하더라도 어느 시점부터 종종 들리는 단어가 있다. 텔레그램 때부터 지겹도록 나오는 E2EE (End-to-End Encryption), 종단간 암호화라는 단어다.

박근혜 씨가 대통령이던 시절 수많은 사찰 논란과 함께 튀어나오기 시작한 그 단어 종단간 암호화. 최근에도 빅테크의 개인정보 이슈가 발생할 때마다 튀어나오는 단어인데, 정작 뭐냐고 물어보면 정확하게 모르는 경우가 많다.

단어를 다 알고 써야 하는 건 아니지만 기왕 알고 있으면 더 좋고 어그로도 한 번 끌어볼 수 있으니까, 종단간 암호화가 뭔지 알아보도록 하자.

기본 개념

서버에 저장되는 정보

만약 당신이 위와 같은 대화를 친구와 카카오톡으로 나눈다고 가정하자. 이 대화의 내용은 당신과 당신의 친구만 볼 수 있을까? 정답은 아니오다.

물론 메신저 앱의 보관 정책에 따라 서버에 데이터가 저장되지 않을 수도 있고, 일정 기간 후 폐기될 수도 있다.

모든 앱에 공통적으로 적용되는 것이 아닌 보편적인 개념이니, 실제 카카오톡이 그렇다고 생각하기보다는 일반적으로 위와 같다고 이해해 주시면 감사하겠다.

많이 사용되는 메신저 앱 중 LINE의 경우 실제로 Letter Sealing이라는 종단간 암호화 기술이 적용되어, 서버에서 대화 내용을 확인할 수 없게 되어있으며, 카카오톡의 경우 비밀채팅은 종단간 암호화로 대화 내용이 보호된다.

서버에 정보가 저장되는 것이 어때서?

우선 본인은 극단적인 개인정보보호주의자는 아니다.

개인정보보호주의자는 실제로 있는 사상이 아니다, 내가 대충 지은거임

대충 이제 모든 Google 서비스를 쓰지 말아야 한다거나, 클라우드를 아예 사용하지 않아야 한다는 등의 의견을 가진 분들을 표현하기 위해 쓴 말이다.

그리고 그 의견에도 일부 동의함, 비꼬는 거 아님.

현업에 있는만큼 그런 데이터들이 왜 서버에 저장이 되어야 하는 건지, 어떤 식으로 활용하는 건지도 대충 이해한다. 하지만, 그럼에도 불구하고 서버에 데이터가 남는다는 사실 자체는 영 찝찝한 느낌이다. https://www.hani.co.kr/arti/society/society_general/658159.html 기사의 일부를 캡처하였다. 특히나, 위와 같이 정부 차원의 민간인 사찰 이야기가 나올 때는 더더욱 불안해질 수밖에 없다.

그걸 종단간 암호화가 해결해주는건가?

그렇다. 정확히는 아래에서 설명하겠지만, 기술적으로는 서버에서 사용자의 데이터를 임의로 읽을 수 없게끔 조치하는 기술이다. 하지만 이 기술에도 약점은 있고, 그로 인해 사용자의 데이터를 서버에서 볼 수 있게되는 경우도 있다. 그 경우도 포함에서 아래에서 상세하게 설명하도록 하겠다.

세부 개념

그러면 이제부터는 기술적인 이야기와 함께 종단간 암호화가 실제로 어떤 식으로 구현되는 것인지 알아보겠다.

시작

종단간 암호화 외에도 현재의 인터넷 통신에는 암호화 기술이 많이 적용되어 있다.

인터넷 사이트 접속 시 주소에 포함되어 있는 HTTPS도 암호화가 적용된 HTTP 프로토콜이고, 은행 거래 시 사용하는 OTP도 암호의 일종이며 DB에 사용자의 비밀번호를 저장할때도 암호화하여 저장하는 등 여기저기서 많이 사용한다.

근데 이렇게 암호화가 많은데 또 추가해야되나? 하는 생각이 들 수 있다. 암호화의 기본적인 개념부터 짚고 넘어가보겠다.

근데 암호화 개념 설명한다고 카이사르 암호니 2차 대전 당시 독일군이 사용하던 에니그마이니 하면 다들 뒤로가기 누르실꺼자너? 그냥 현대에서 많이 사용되는 암호화 방식만 빠르게 짚고 넘어가겠다.

여러가지 암호화 방식

위에서 설명한 암호화가 사용되는 여러 케이스에서도 각각 암호화 방식들이 다른 경우가 많다.

예를 들어 HTTPS는 대칭키 암호화와 비대칭키 암호화를 함께 사용한다.

대칭키 암호화는 암호화와 복호화에 같은 키를 사용하는 암호화 방식이다.

A라는 정보가 담겨있는 금고가 있을 때, 이 정보를 볼 수 있는 B와 C가 같은 열쇠를 하나씩 가지고 있는 개념이다.

이 방식의 경우 열쇠가 정해져있기 때문에 암/복호화를 수행할 때 속도가 빠르지만 열쇠를 전달하는 과정에서 열쇠가 노출될 수 있다는 약점이 있다.

열쇠를 주고 받는 과정 중 열쇠가 노출된다면 금고의 복사 열쇠가 생기는 것이나 마찬가지이기 때문에, 대칭키 암호화를 수행할때는 믿을 수 있는 경로로 열쇠를 전달하는 것이 중요하다.

비대칭키 암호화 (공개키 암호화)는 암호화와 복호화에 사용하는 키가 서로 다른 암호화 방식이다. 이 암호화 방식에는 공개키와 비밀키가 존재한다.

이름 그대로 공개키는 모두에게 공개할 수 있는 키고, 비밀키는 키를 생성한 본인만 갖고 있어야하는 키이다.

원칙적으로는 그렇지만, 구현에 따라서는 공개키를 본인만 갖고 있고 비밀키를 공개할수도 있다. 아무튼 중요한 점은 하나는 공개하고 하나는 비밀이라는 것

암호화를 수행할때는 공개키를 사용하고 복호화할때는 비밀키를 사용한다. 만약 A라는 사람과 B라는 사람이 서로 메세지를 주고 받는다고 가정해보자.

먼저 B라는 사람이 본인의 공개키를 공개한다. 이때 공개하는 방식은 여러가지이다. A에게 직접 본인의 공개키를 얘기해줄수도 있고, 여러 사람이 볼 수 있는 칠판에 공개키를 적어놓을수도 있겠다. 어떤 방식을 사용하던 중요한 점은 B의 공개키가 A에게 전달되어야 한다는 것이다.

그 다음 A는 B의 공개키를 사용하여 메세지를 암호화한다. 그 후 B에게 암호화된 메세지를 전달한다. 이때도 어느 수단을 사용하던지 상관 없다, 중간에 탈취되더라도 B외의 다른 사람은 이 메세지를 복호화할 수 없다.

그 후, B는 본인의 비밀키를 사용하여 이 메세지를 복호화한다.

공개키 암호화는 위와 같은 과정으로 암/복호화가 이루어진다. 이렇게 공개키 암호화를 사용하면 키를 전달하는 것이 어렵다는 대칭키 암호화의 단점이 보완된다. 하지만 공개키 암호화도 약점이 없는 것은 아니다.

공개키 암호화의 주요 약점은 위에서 얘기한 공개키를 전달하는 방식이다. 키를 전달하는것이 어렵다는게 보완됐다며? 싶겠지만, 그 단점이 보완된 것은 맞지만 전달받은 공개키를 믿을 수 있냐는 다른 문제이다.

예를 들어서, 위에서 예시를 들었던대로 B가 본인의 공개키를 여러 사람이 볼 수 있는 칠판에 적어놓았다고 가정해보자. 이때, B를 질투하는 C가 B가 적어둔 공개키를 지우고 본인의 공개키를 적었다. 이런 경우 A가 B의 공개키인줄 알고 사용을 했는데 사실은 C의 공개키이기 때문에, B는 메세지를 복호화할 수 없고 C는 이 메세지를 복호화 할 수 있다.

또는, C가 B의 공개키 아래에 자신의 공개키도 적어두어 B의 공개키가 2개인 것처럼 적어두었다고 가정해보자. 그리고 A가 B에게 보내기 위해 B의 공개키로 보이는 2개를 모두 사용하여 암호화하여 메세지를 보내게 되면, A가 B에게 보낸 메세지를 B와 C가 모두 볼 수 있는 경우가 생긴다.

이를 중간자 공격 (Man In the Middle Attack, MITM) 이라한다. 이런 약점들을 보완하기 위해 공개키 암호화를 사용하는 경우에는 이 약점을 보완하기 위해 여러 기술들을 이용하고 있다. 상세한 이야기는 아래에서 추가로 설명하도록 하겠다.

이외에도 해시 함수 등 여러 암호화 방식들이 있지만, 이 게시글에서는 크게 중요한 사항은 아니니 별도로 설명하지는 않겠다.

공개키 암호화

그래, 다양한 방법이 있는건 알겠는데 그래서 종단간 암호화에서는 무슨 방식을 쓰는건가요?

종단간 암호화를 구현할 때는 일반적으로 공개키 암호화를 사용한다.

종단간 암호화는 발신자와 수신자는 내용을 확인할 수 있지만 서비스의 사업자는 내용을 확인할 수 없어야 하기 때문에 대칭키 암호화가 아닌 공개키 암호화를 사용하고, 서비스 내에서 키 교환이 이루어지도록 처리한다.

기본적인 개념은 모두 위에서 설명한 공개키 암호화의 설명과 동일하다. 사용자는 서비스에서 본인의 개인키와 공개키를 생성하며, 개인키는 기기에 공개키는 서버에 저장된다.

서비스마다 차이가 있을 수 있지만, 스마트폰 어플리케이션들의 경우 개인키를 일반적으로는 iOS 기준 Secure Enclave, Android 기준 Keystore에 저장한다.

물론 서비스마다 저장소가 다를 수 있고, 서비스의 형태에 따라 또 다를 수 있다.

본 게시글의 내용은 일반적인 인스턴트 메신저에서의 종단간 암호화에 대해 다루고 있다.

그리고 키 교환을 수행하게 되는데, 이 키 교환의 과정은 서비스마다 구현 방식이 다르다.

공개키 서버

공개키 서버는 서비스의 서버를 전적으로 신뢰하고, 상대방의 공개키를 서비스의 서버에서 다운받아 사용하는 방식이다. 대부분의 메신저들이 이 방식을 사용해 구현하고 있지만, 이 방식의 경우 특성 상 서버에서 사용자의 공개 키를 변조하는 등의 행위로 종단간 암호화를 간단하게 무력화할 수 있기 때문에 중간자 공격에 취약하다.

실제 서비스들이 그러고 있다는게 아니라, 이론적으로 그럴 수 있다는 가정에 불과하다.

하지만 종단간 암호화는 서비스사도 신뢰할 수 없을때도 안심하고 사용할 수 있도록 하는 기술이기 때문에, 이러한 단점은 이론상으로만 가능하더라도 경각심을 가져야하는 단점이다.

서비스사가 그러지 않겠다는 약속만으로 보안이 지켜지는 것이라면, 굳이 종단간 암호화를 적용할 필요 없이 우리는 데이터를 제공하지 않습니다 라는 약속만 해도 별 다를 것이 없으니까.

물론 서비스들 중 이러한 사용자들의 걱정을 해소하기 위해서 클라이언트 혹은 서버까지 오픈소스로 공개하는 Telegram, Signal 등의 서비스들도 있다.

이런 서비스들의 경우 Reproducible Builds라 하여 사용자가 직접 빌드하여 보안성을 검증할 수 있도록 하는 서비스들도 있다.

이러한 움직임은 사용자의 걱정을 해소하기 위한 움직임으로 보여 괜찮게 생각하지만, 현재 오픈소스로 공개된 서비스들도 서버가 공개되지 않은 Telegram이라던지, 서버는 공개되어 있지만 빌드의 재현이 사실상 불가능한 Signal등의 각 서비스들의 한계점이 있어 이러한 부분이 보완되었으면 하는 바램이다.

실제로 Telegram의 경우 자체 프로토콜인 MTProto의 취약점으로 인해 메세지의 열람이 가능한 문제가 있었다.

미공개 된 부분이나, 공개되어 있더라도 상세한 확인이 현실적으로 어려운 부분들에서 문제가 발생하면 언제든지 보안 이슈가 발생할 수 있다.

오프라인 교환

키 교환 방식 중 가장 신뢰할 수 있는 방식이지만, 현실적으로 이 방식을 사용하기에는 어려움이 있다. 사실 만날 수 있으면 메신저로 해야할 이야기를 직접 전달할 수도 있으니까.

그래도 이런 방식이 가능해서 나쁠 것은 없고, Signal과 같이 보안을 주요 메리트로 가져가는 서비스들은 QR코드를 통해 오프라인 공개키 교환을 할 수 있는 기능을 제공하고 있다.

신뢰할 수 있는 보증인이 보증하는 방법

공개키 서버와 유사하나 키 교환을 서비스사가 아닌 외부인 또는 외부 기관이 수행하는 방식이다.

HTTPS에 사용되는 인증서들은 실제로 이 방식으로, 신뢰할 수 있는 루트 기관 (ex: Sectigo, DigiCert) 등이 인증서를 발급하고 그 인증서를 통해 사이트를 확인하는 방식을 사용한다.

하지만 개인정보 이슈는 대부분 나외에 다른 사람을 신뢰하지 못해서 발생하기 때문에, 이 또한 외부 기관이 인증서 등을 변조하여 문제가 발생할 수 있다는 단점이 있다.

이론상의 문제라기에는, 실제로 대한민국 정부는 GPKI 인증서의 부정 발급 문제로 대부분 브라우저 제조사에서 Root CA를 박탈당한적이 있다.

결론

좀 갑자기 게시글을 끝내는 것 같은데, 너무 오랜만에 게시글을 작성하다보니 감을 잃어버려서 더이상 어떻게 전개해야 될지 모르겠어서 여기서 게시글을 끝내겠다.

아무튼 종단간 암호화는 위와 같은 기술적인 한계들을 안고 있지만, 그럼에도 불구하고 현 상황에서 개인정보를 보호하기 위한 가장 나은 방법이라는 것에는 변함이 없다.

사실 관심이 많이 적은 분야지만, 사용자의 프라이버시를 지키고 서비스의 보안을 향상시키기 위한 노력은 전세계 각지에서 지속적으로 이루어지고 있으며, 언제든 더 나은 방법이 나와 위와 같은 단점들이 해결될 수 있다.

이러한 발전의 원동력은 여러분들의 보안 및 개인정보에 대한 관심이기 때문에, 이번 게시글을 통해서 관심이 생겼다면 종단간 암호화 기술 자체에 대한 관심과 이를 실제로 구현하는 서비스 업체들을 항상 의심의 눈초리로 봐주었으면 좋겠다.

농담삼아 의심의 눈초리라고 이야기했지만, 이런 보안 관련 기술은 항상 기존 기술에 대한 의심과 검증을 통해 발전한다고 개인적으로 생각한다.

기술의 발전을 위해서라도 말이 좀 이상하지만 많은 의심 부탁드린다.

p.s

본인은 암호화 기술에 많은 관심을 갖고 있고, 일부 개념은 현업에서 사용하지만 당연히 일상적으로 암호 관련 기술을 다루는 현업자나 전공자에 비해서는 부족한 점이 많다.

부족한 점이나 더 추가되었으면 하는 점을 알려주시면 받아들이고 개선할 준비가 되어 있으니 거리낌 없이 의견을 던져주시면 감사하겠습니다. 🙇