1. E2E 암호화 구현 질문
최근에 E2E 구현 관련 질문을 받았다. 아쉽게도 E2E 암호화를 어떻게 구현하는지 전혀 몰라서 제대로 대답하지 못했다. 오늘은 E2E란 무엇이고, 어떻게 구현할 수 있는지, 나의 이전 토이 프로젝트에는 어떻게 적용할 수 있었을 것 같은지 정리한다.
Q : "토이 프로젝트로 진행하셨던 '모디'(OTT 계정 공유 서비스)에서 계정 공유를 위해 대칭키를 사용하셨던데, 이것을 E2E 암호화로 하여 서버에서도 계정을 알 수 없게 하려면 어떻게 해야할까요?"
A : ...
2. E2EE란?
End to End Encrpytion의 약자로, 연결된 양 종단기기만 서로 평문을 볼 수 있도록 하고 그 사이에는 복호화 할 수 없는 암호문만 전달하는 것이다. Viber 같은 VoIP 서비스나 텔레그램 같은 메신저 서비스에서 이를 홍보하는 것을 종종 보았을 것이다. 해당 서비스들의 서버는 암호문만 가지고 있고, 이를 복호화 할 수 있는 키를 가지고 있지 않기 때문에 해당 서비스의 회사에서도 평문을 알 수 없어 보안적 측면에서 각광을 받는다.
3. E2EE의 구현
비대칭키의 개념을 알고 있다면 E2EE의 구현은 어렵지 않다. 만약 비대칭키가 무엇인지 모른다면 CDN URL 서명과 관련된 글에 정리해놓은 내용을 참고하자. 비대칭키를 이용한 E2EE에서 핵심은 복호화가 가능한 키를 사용자 로컬에만 가지고 있는 것이다. 채팅 서비스를 간단한 예시로 단계별 설명하면 아래와 같다.
- 사용자 A와 B는 비대칭키를 생성한다. 공개키를 서버에 저장하고, 비공개키는 핸드폰에만 저장한다
- 사용자 A와 B가 같은 채팅 방에 접속한다
- 사용자들은 다른 사용자들의 공개키에 접근할 수 있다.
- 사용자 A가 B에게 채팅을 보낼때, 채팅 내용을 B의 공개키로 암호화 한뒤 전송한다.
- 서버는 채팅 암호문을 B에게 전달한다. 이때 서버는 비공개키가 없으므로 채팅 내용을 알 수 없다
- 사용자 B가 채팅 암호문을 수신하고, 자신의 비공개키로 복호화한다
보안적으로는 더 좋아졌지만 성능적인 시사점도 잊지는 말자. 비대칭키 암호화는 대칭키보다 느리고, 위에서 설명한 방식으로 E2EE를 구현하기 위해서는 채팅을 받아야하는 사람 수만큼 암호화해서 보내야한다. 하지만 E2EE에 사용될 클라이언트가 90년대 슈퍼컴퓨터와 맞먹는 스마트폰인점을 생각해보면 큰 문제가 아닐 수 있다.
4. 모디에 E2EE를 적용한다면?
모디 서비스의 간단한 흐름을 정리한뒤 E2EE를 어떻게 적용할 수 있을지 생각해보자. 모디에서는 OTT 계정을 공유할 파티라는 단위가 있다. 파티장은 OTT 계정의 주인으로서 구독료 부담을 줄이고자 파티를 생성하여 파티원을 모집한다. 원하는 파티원 수와 공유할 OTT 계정은 파티 생성 시점에 등록 해논다. 다른 이용자들은 모집 게시판을 통해 파티에 참여할 수 있다. 파티 인원 수가 충족된다면 파티가 시작되고, 파티원들은 계정을 공유 받을 수 있다. 이 기능에 E2EE를 적용한다면 2가지 방향으로 해볼 수 있을 것 같다
옵션 1. 파티 시작시에 계정 작성
E2EE를 위해서는 메시지를 보낼 사용자의 공개키가 필요하다. 하지만 파티 생성 시점에는 파티원의 공개키를 알 수 없다. 따라서 파티원의 모든 공개키를 알 수 있는 파티원 모집 완료 이후 파티장에게 알림을 푸시해 계정을 작성하도록 하고, 계정 공유를 시작한다. 하지만 이 방식은 사용성 문제가 있다. 애초에 파티 생성 시에 계정을 작성하도록 한 이유가, 파티장의 추가적인 승인 절차 없이 파티가 시작할 수 있도록 하기 위함이었다. 파티 시작 전에 파티장이 계정을 입력한다면, 파티원들은 파티 모집이 완료되었음에도 불구하고 파티장이 계정을 입력할때까지 기다려야한다.
옵션 2. 파티 생성시에는 대칭키, 모집 후 비대칭키
옵션 1의 문제를 해결하기 위해 팀 생성 시에는 대칭키로 암호화하고, 모집 완료 후 비대칭키로 암호화할 수 도 있다. 이 경우 사용성 측면에서는 기존 대칭키만 사용하는 것과 다르지 않다. 그리고 파티 모집 완료 이후에는 비대칭키로 서명하여 서버에서 복호화할 수 없게 만드는 등 기존 방식보다는 보안성을 더 높일 수 있다. 하지만 어찌됐던 일정 시점 동안에는 서버에서 복호화가 가능하기 때문에 E2EE라고 하기에는 어렵다. 결국 어떤 옵션을 선택하는지는 정책에 따라 달라질것 같다.
