엔드투엔드 암호화 설명: 초보자 가이드

엔드투엔드 암호화(E2EE)는 파일을 발신자의 기기에서 암호화하여 수신자만 복호화할 수 있는 방식입니다. 전송 서비스는 암호문(ciphertext)만 이동시킬 뿐 복호화 키를 보유하지 않습니다. 따라서 서비스 직원, 해커, 법원 영장 모두 파일 내용을 읽을 수 없습니다. 브라우저가 256비트 AES 키를 생성하여 로컬에서 파일을 암호화하고, 암호문을 업로드한 뒤 키를 공유 링크의 # 뒤 fragment에 삽입합니다. 브라우저는 fragment를 서버에 전송하지 않으므로 키가 외부로 유출되지 않습니다.

"엔드투엔드"의 진짜 의미

두 개의 "끝(end)"은 발신자와 수신자입니다. 그 사이에 있는 모든 것 — ISP 라우터, CDN 엣지, 전송 서비스 서버, 수신자의 ISP — 은 중간 경유지에 불과합니다. E2EE를 사용하면 이 중간 구간은 암호화된 바이트만 봅니다. 전송 계층 암호화(TLS)만 사용하는 경우와 비교하면, TLS는 브라우저에서 서버까지의 데이터를 보호하지만 서버가 복호화한 뒤 평문을 저장하고 수신자가 다운로드할 때 다시 암호화합니다. WeTransfer의 기본 서비스가 이 방식으로 동작합니다. E2EE를 사용하면 검사가 서비스 제공자에게 영장을 제시해도 무작위 바이트처럼 보이는 암호문만 제출할 수 있습니다. 그렇기 때문에 언론인, 변호사, 의사들이 E2EE를 점점 더 많이 요구합니다.

TLS만으로는 부족한 이유

TLS 1.3은 커피숍에서의 패킷 스니핑이나 악성 ISP의 도청을 막는 데 탁월합니다. 그러나 TLS는 서버에서 종료됩니다. 암호화 터널이 끝나면 서버는 원본 파일을 처리합니다. 만약 그 서버가 침해된다면 — 2022년 Dropbox 소스 코드 및 고객 데이터 유출 사례처럼 — 저장 중인 파일에 대해 TLS는 아무런 보호도 제공하지 않습니다.

E2EE는 서버 침해에도 살아남는 두 번째 방어 계층을 추가합니다. 파일은 네트워크에 닿기 전에 암호화되고, 수신자의 브라우저가 복호화할 때까지 암호화 상태를 유지합니다. 데이터베이스 전체가 유출되어도 암호문과 메타데이터만 노출됩니다.

URL Fragment를 이용한 키 전달

E2EE에서 까다로운 부분은 서버가 키를 보지 않고 수신자에게 전달하는 것입니다. 현대 브라우저 기반 서비스는 URL fragment 방식으로 이 문제를 해결합니다. 공유 링크의 형태는 다음과 같습니다.

https://hexatransfer.com/download/abc123#k=base64-encoded-256-bit-key

브라우저는 # 이후의 모든 내용을 클라이언트 측 fragment로 처리합니다. 링크를 클릭하면 서버는 HTTP 요청에서 /download/abc123만 수신하며, fragment는 브라우저 밖으로 나가지 않습니다. JavaScript가 fragment에서 키를 읽고, 암호문을 가져온 뒤 Web Crypto API의 crypto.subtle.decrypt()를 사용하여 로컬에서 복호화합니다. 이 방식은 RSA 키 교환이나 Diffie-Hellman보다 단순하고 브라우저만 있으면 누구나 사용할 수 있습니다.

서버가 볼 수 있는 것과 없는 것

올바르게 구현된 E2EE에서 서버 로그에는 보통 무작위 파일 ID, 암호문 크기, 업로드 IP, 업로드 타임스탬프, 중복 제거용 SHA-256 해시가 포함됩니다. 서버는 파일명, 파일 내용, 수신자 신원, 복호화 키를 볼 수 없습니다. 파일명은 종종 내용과 함께 암호화되어 암호문 헤더의 일부로 저장됩니다.

실용적인 검증 방법: 서비스 제공자에게 영장 발부 시 무엇을 제출할 수 있는지 물어보세요. 진정한 E2EE 서비스는 "암호화된 블롭과 IP 로그"라고 답할 것입니다. 평문 파일을 제출할 수 있다면 암호화는 엔드투엔드가 아닙니다.

내부에서 사용하는 알고리즘

실제 E2EE 스택은 검증된 소수의 기본 요소를 사용합니다.

AES-256-GCM: 파일 대량 암호화에 사용됩니다. GCM은 기밀성과 인증을 동시에 제공하므로 변조된 암호문은 복호화 실패로 이어집니다.
PBKDF2 (최소 100,000회 반복) 또는 Argon2id: 패스워드 보호 추가 시 키 파생에 사용됩니다.
SHA-256: 무결성 해시에 사용됩니다.
TLS 1.3: 외부 전송 계층으로 추가 보호를 제공합니다.

HMAC 없이 AES-CBC를 사용하거나, MD5 또는 SHA-1을 사용하거나, PBKDF2 반복 횟수가 10,000 미만인 서비스는 피하십시오.

파일 전송 E2EE vs 메시징 E2EE

Signal은 Double Ratchet 프로토콜로 채팅의 E2EE를 대중화했고, 순방향 비밀성을 위해 매 메시지마다 키를 교체합니다. 파일 전송은 일회성이므로 그 복잡성이 필요하지 않습니다. 업로드마다 새로 생성되는 파일당 하나의 대칭 키로도 충분하며, 감사하기도 더 쉽습니다. 파일 전송에서 메시징과 다르게 필요한 것은 재개 가능한 청크 업로드(파일이 10 GB일 수 있음), 청크 간 무결성 검증, 수신자 계정 없이 작동하는 링크입니다. Tresorit, Proton Drive, SwissTransfer, HexaTransfer 모두 이 방식을 채택합니다.

서비스가 진정한 E2EE인지 확인하는 방법

서비스를 신뢰하기 전에 다음 네 가지를 실제로 확인하십시오.

작은 파일을 업로드하는 동안 DevTools → Network를 엽니다. 요청 본문에 평문이 보이면 클라이언트 측 암호화가 아닙니다.
URL fragment(# 이후)에 키가 있는지 확인합니다. fragment 키가 없으면 서버가 키를 보유하는 것입니다.
"파일에 접근할 수 없습니다"라는 언어와 기술적 설명이 함께 있는 개인정보 처리방침을 읽어보십시오.
클라이언트 코드를 감사할 수 있는지 확인합니다. 오픈 소스이거나 적어도 문서화되어 있어야 합니다.

네 가지를 모두 충족하는 서비스: SwissTransfer(클라이언트 측 암호화 티어), Tresorit Send, Proton Drive 공유 링크, HexaTransfer.

E2EE가 보호하지 않는 것

E2EE는 만능이 아닙니다. 다음은 보호하지 않습니다.

감염된 엔드포인트: 노트북에 악성코드가 있다면 공격자는 암호화 전에 파일을 읽습니다.
유출된 공유 링크: 링크를 가진 사람은 누구나 다운로드하고 복호화할 수 있습니다.
취약한 패스워드: PBKDF2가 무차별 대입 공격을 늦추지만 간단한 패스워드는 금방 뚫립니다.
메타데이터: 타임스탬프, 파일 크기, IP 주소는 여전히 정보를 노출합니다.

민감한 전송에는 E2EE와 함께 만료 링크(24시간이 적절한 기본값), 다운로드 횟수 제한, 강력한 패스워드를 함께 사용하십시오.

hexatransfer.com에서 사용해 보세요 — 무료, 계정 불필요, 최대 10GB.