【제28회】 서버에 로그를 전혀 남기지 않는! WebRTC DataChannel을 활용한 종단 간 암호화 P2P 채팅의 시작

안녕하세요! 2채널 호환 게시판 시스템 「츠우바이채널(つゔぁいちゃんねる, 2ch.biz)」 개발 기록입니다.

지난번(제27회)을 기점으로 제1부 '게시판 코어 기능・초기 보안・관리 운영 기반편'이 무사히 완료되었습니다.

이번부터 본 연재는 완전히 새로운 도전인 **「제2부: WebRTC를 이용한 완전 서버리스 P2P 암호화 채팅 개발 기록」**으로 돌입합니다!

그 첫 번째 글인 본고에서는, 중앙 서버에 메시지나 파일의 로그를 1글자, 1바이트도 남기지 않는, **WebRTC DataChannel (Full-Mesh)**과 **AES-GCM 256bit 종단 간 암호화(E2EE)**를 결합한 완전 익명 P2P 채팅 시스템 구축에 대해 아키텍처부터 구현 코드까지 철저하게 해설합니다.

일반적인 웹 게시판이나 채팅 서비스(Discord, LINE, Slack 등)에서는 모든 발언 데이터가 중앙 서버의 데이터베이스에 영구 저장됩니다.

하지만 여기에는 운영자와 이용자 양측 모두에게 중대한 과제가 존재합니다.

• 프라이버시 및 법적 리스크:- 데이터베이스에 대화 로그나 업로드 파일이 축적될수록 정보 유출이나 사이버 공격, 수사 영장에 대응하는 비용이 막대해집니다.

• 인프라 유지 비용의 증가:- 실시간 채팅으로 WebSocket 연결을 계속 유지하고, 방대한 메시지나 대용량 파일을 저장·전송하게 되면 서버의 대역폭・CPU・스토리지 비용이 지수 함수적으로 폭발합니다.

• 「로그가 남지 않는 장소」를 원하는 사용자 니즈:- 인터넷 게시판의 긴 역사 속에서, 「이 스레드의 거주자와 실시간으로 이야기하고 싶지만, 흔적(로그)은 일절 남기고 싶지 않다」「그 자리 한정의 찰나적인 대화나 파일 교환을 즐기고 싶다」라는 강한 수요가 항상 존재해 왔습니다.

그래서 저희가 내린 결정이, 「메시지나 파일을 서버에 전혀 저장하지 않고, 참여자 간의 브라우저 사이에서 직접 통신(P2P)하게 하는」 아키텍처였습니다.

P2P 통신을 실현하기 위해서는, 참여자들끼리 서로의 글로벌 IP나 포트 번호, 암호화 파라미터(SDP: Session Description Protocol 및 ICE Candidate)를 교환하는 **「시그널링(Signaling)」**이 필요합니다.

시그널링 서버는 「매칭 전화를 연결해 주는 사람」 역할로만 기능하며, P2P 연결이 확립되는 순간 통신 경로에서 완전히 퇴장합니다.

• Zero Storage (제로 스토리지): 서버 측 DB에는 테이블조차 만들지 않습니다. -
• Zero In-transit Inspection (중간 가로채기 완전 배제): 서버는 암호문 복호화 키를 가지고 있지 않습니다. 브라우저 간에 종단 간 암호화됩니다. -
• Room Auto-Destruction (방의 즉시 자동 소멸): 참여자가 0명이 되는 순간, 시그널링용 메모리는 즉시 해제됩니다.

WebRTC 자체도 DTLS (Datagram Transport Layer Security)에 의해 전송로 상에서 암호화되지만, 만일의 중간자 공격(MITM)이나 시그널링 가로채기에 대비하여 애플리케이션 계층에서도 Web Crypto API를 사용한 이중 암호화를 진행하고 있습니다.

룸 패스코드(또는 URL 프래그먼트 내의 시드)로부터 PBKDF2로 256bit의 공통 키를 도출하고, 메시지마다 무작위인 96bit IV (초기화 벡터)를 생성하여 AES-GCM으로 암호화합니다.

/**
* Web Crypto API를 사용한 E2EE 암호화・복호화 모듈
*/
...

츠우바이채널의 아이덴티티인 「익명성」과 「개인 식별(고정 핸들)」을 양립시키기 위해, P2P 채팅 내에서도 게시판 본체와 **100% 동일한 트립(SHA-1 계산)**을 클라이언트 완결로 생성할 수 있게 했습니다.

입력란에 명無しさん#secretKey

라고 입력하면, 실시간으로 다음과 같이 분해・변환됩니다.

/**
* 2ch 호환의 트립 생성 (클라이언트 완결판)
*/
...

이를 통해 사용자는 서버에 비밀 키(비밀번호)를 전송하는 것 없이, 자신의 고정 핸들을 P2P 룸 내에서 증명할 수 있습니다.

UI는 옛날 IRC 클라이언트(XChat / HexChat)의 기능미를 리스펙트한 디자인으로 완성했습니다.

• 자유 가변 사이즈 창 (: `resize: both``} ]

）＆최대화 기능- 데스크톱에서는 오른쪽 아래 손잡이로 자유롭게 크기 조절 가능. 최대화 버튼（🗖）을 누르면 전체 화면 채팅으로 변신합니다.

• 데스크톱에서는 오른쪽 아래 손잡이로 자유롭게 크기 조절 가능. 최대화 버튼（🗖）

• 전통적인 2컬럼 메시지 로그:- 왼쪽 열(오른쪽 정렬 발언자명 + 트립) ｜ 수직 구분선（|） ｜ 오른쪽 열(메시지 본문). - 발언이 아무리 빠르게 흘러도, 누가 말했는지 한눈에 파악할 수 있습니다.

• 왼쪽 열(오른쪽 정렬 발언자명 + 트립) ｜ 수직 구분선（|）

• 닉네임 사이드바:- 방 참가자 목록을 오른쪽에 상시 표시. 호스트(방장)에게는 @ 접두사가 붙습니다.

• 방의 참가자 목록을 오른쪽에 상시 표시. 호스트(방장)에게는

• 인프라 비용 제로:- 아무리 오랜 시간 잡담이 오가거나, 기가바이트 단위의 사진이나 zip 파일이 주고받아져도 서버 전송량은 시그널링에 필요한 수KB에 불과합니다.

• 완벽한 프라이버시 보호:- 서버 운영자라 하더라도 누가 어떤 대화를 나누었는지 알 방법이 없습니다. 로그가 존재하지 않기 때문에, 유출 위험 자체가 원리적으로 제로입니다.

• 초고속 응답성:- 도쿄와 오사카 사용자 간이라면 지연은 단 몇 밀리초에 불과합니다. 서버를 중계하지 않기 때문에, 타이핑의 생생함 그대로 메시지가 도착합니다.

훌륭하게 시작한 P2P 암호화 채팅이었지만, 게시판 사용자들로부터 곧바로 다음 요청이 도착했습니다.

"채팅은 최고인데,

게시판 스레드를 읽으면서 동시에 채팅하고 싶다"

"스레드 URL을 클릭해서 다른 화면으로 이동하면, P2P 연결이 끊겨 방에서 퇴실 처리되어 버린다!"

SPA(Single Page Application) 환경에서 WebRTC 연결을 유지한 채로 스레드 열람과 채팅 화면을 매끄럽게 오가려면 어떻게 해야 할까요?

본 서비스: https://2ch.biz/