영지식 아키텍처: 서버가 당신의 파일을 볼 수 없는 이유

영지식(zero-knowledge) 아키텍처란 서비스 제공자가 기술적으로 사용자의 파일을 읽을 수 없는 구조를 의미합니다. 암호화 키는 절대 서버에 도달하지 않고, 마스터 키도, 백도어도, "우리를 믿으세요"도 필요하지 않습니다. 브라우저가 업로드 전 AES-256-GCM으로 파일을 암호화하고, 그 키는 URL fragment(# 이후)를 통해 수신자에게만 전달됩니다. 브라우저는 fragment를 서버에 전송하지 않으므로, 유효한 법원 영장이 있더라도 제공자는 암호문만 제출할 수 있습니다. Tresorit, Proton, SwissTransfer, HexaTransfer가 채택한 이 모델은 "저장 시 암호화"와 수학적으로 다릅니다.

서버가 제출할 수 있는 것이 증명이다

영지식의 가장 명확한 검증: 강제될 경우 회사가 무엇을 제출할 수 있을까요? Google Drive, Dropbox, OneDrive 같은 전통적인 클라우드 스토리지는 파일을 평문으로 제출할 수 있습니다. Google의 2023년 투명성 보고서에 따르면 미국 정부 데이터 요청의 83%에 응하여 법적으로 요구된 사용자 콘텐츠를 제공했습니다. 이는 Google 보안의 실패가 아니라 아키텍처가 그렇게 작동하는 것입니다.

영지식 서비스는 다음만 제출할 수 있습니다.

암호화된 파일 블롭(키 없이는 무용지물)
계정 메타데이터(이메일, 가입 IP)
업로드/다운로드 IP 주소 및 타임스탬프
해당되는 경우 결제 정보

파일명, 내용, 수신자 신원, 복호화 키는 제출할 수 없습니다. 거부하는 것이 아니라 가지고 있지 않기 때문입니다.

URL Fragment 트릭의 정밀한 원리

핵심 기술은 URL fragment를 비공개 키 채널로 사용하는 것입니다. 브라우저가 https://hexatransfer.com/d/xyz789#k=BASE64KEY를 요청할 때 서버에는 GET /d/xyz789만 전송됩니다. fragment는 브라우저의 주소 표시줄에만 남아 있습니다. JavaScript가 window.location.hash로 키를 읽고 crypto.subtle.decrypt()에 전달합니다.

이 방식은 2013년경 Mega.nz가 개척하고, Mozilla가 2020년 서비스를 중단하기 전 Firefox Send가 정교화했습니다. HTTP RFC 3986이 fragment를 클라이언트 측 전용으로 정의하므로, nginx나 Caddy의 서버 액세스 로그에는 fragment가 기록되지 않습니다. 이론적으로 제공자가 클라이언트 측 JavaScript로 fragment를 로깅할 수 있기 때문에, 영지식 서비스는 클라이언트 코드를 공개하고 별도 출처에서 제공되는 서명된 정적 자산으로 배포하는 경우가 많습니다.

"저장 시 암호화"와의 차이

모든 클라우드 제공자는 저장 시 파일을 암호화합니다. SOC 2 Type II 및 ISO 27001 인증에 보통 요구되는 기본 사항입니다. 그러나 제공자가 키를 보유한 "저장 시 암호화"는 도난된 디스크의 공격자에게만 불투명하며, 제공자가 요청 시 자동으로 복호화할 수 있습니다.

영지식은 키 보관 구조를 뒤집습니다. 사용자가 키를 보유하고 제공자가 암호문을 보유합니다. 제공자는 복호화할 수 없으므로 얻는 이득이 없습니다. 이것이 중요한 세 가지 위협 시나리오는 다음과 같습니다.

내부자 위협: 데이터베이스 접근 권한을 가진 직원도 암호문만 봅니다.
정부 요청: GDPR 제48조 및 미국 CLOUD Act 요청이 공개를 강제할 수 있지만, 보유하지 않은 것은 공개할 수 없습니다. 한국의 개인정보보호법(PIPA) 역시 동일한 보호 논리가 적용됩니다.
서버 침해: 2021년 LastPass 침해는 암호화된 볼트를 노출했지만, 영지식 설계 덕분에 대규모 평문 노출을 막았습니다.

암호화되는 것과 메타데이터

단순한 구현은 파일 내용만 암호화하고 파일명, 크기, 폴더 구조를 그대로 노출합니다. 진정한 영지식은 파일명도 암호화합니다. 보통 {"name": "Q4-financials.pdf", "type": "application/pdf"} 같은 JSON 헤더를 파일 바이트 앞에 붙인 뒤 AES-GCM으로 전체를 암호화합니다.

숨기기 어려운 메타데이터:

파일 크기: 암호문 길이가 평문 길이를 근사합니다.
업로드 타이밍: 타임스탬프와 다른 데이터를 연관시키면 정보가 노출될 수 있습니다.
IP 주소: 제공자는 누가 업로드하고 다운로드했는지 봅니다.

인증 문제

서버가 파일을 복호화할 수 없다면 낯선 사람이 다운로드하지 못하도록 어떻게 인증할까요? 세 가지 일반적인 패턴이 있습니다.

링크 기반 인증: URL(및 fragment) 소유가 곧 권한입니다. SwissTransfer, HexaTransfer, Tresorit Send가 사용합니다. 계정 없이 작동하는 단순한 방식입니다.
패스워드 보호 링크: URL fragment에 솔트가 포함되고, 실제 키는 패스워드에서 PBKDF2로 파생됩니다.
계정 기반 영지식: Proton과 Tresorit은 로그인 패스워드에서 Argon2id로 마스터 키를 파생하여 서버에 암호화된 상태로 저장된 파일별 키를 잠금 해제합니다.

영지식을 깨는 구현 함정

실제 세계의 주요 실패 사례:

서버 측 파일 미리보기: 썸네일 생성이나 검색을 위한 텍스트 추출은 평문이 필요합니다.
동기화 충돌 해결: 기기 간 파일 내용 비교는 보통 평문이 필요합니다. Syncthing과 Cryptomator는 클라이언트 측 diff로 이를 처리합니다.
분석 SDK: Google Analytics나 Segment 같은 제3자 스크립트는 클라이언트 코드에서 window.location.hash를 읽을 수 있습니다.
패스워드 재설정: 제공자가 패스워드를 재설정해도 이전 파일에 계속 접근할 수 있다면 복구 키를 보유하는 것이므로 영지식이 깨집니다.

진정한 영지식을 제공하는 서비스

제3자 감사(Cure53, NCC Group, Trail of Bits)로 검증된 영지식 주장을 가진 서비스 목록:

Tresorit: 스위스, SOC 2 Type II, 영지식 파일 동기화 및 Send.
Proton Drive: 스위스, Proton Mail 암호화 모델 기반.
SwissTransfer: 무료 티어에서 선택적 E2EE 제공, Infomaniak 운영.
Mega.nz: 뉴질랜드, 암호화 백서 공개.
HexaTransfer: 브라우저 기반, 계정 불필요, 전송당 최대 10 GB.

암호화되지만 영지식이 아닌 서비스: Google Drive, Dropbox, OneDrive, Box, iCloud(고급 데이터 보호 티어 제외), WeTransfer 기본 티어.

서비스 신뢰 전 체크리스트

민감한 파일을 맡기기 전 이 체크리스트를 실행하십시오.

개인정보 처리방침에 "파일을 읽을 수 없다"고 명시되어 있는가?
AES-256-GCM과 KDF를 명시한 보안 백서가 공개되어 있는가?
공유 URL에 fragment(# 이후 텍스트)가 포함되어 있는가?
최근 24개월 이내의 제3자 감사 보고서가 있는가?
클라이언트 코드가 오픈 소스이거나 감사 가능한가?

네 가지 이상 충족되면 영지식 서비스입니다. 세 가지 이하이면 제공자가 파일을 볼 수 있습니다.

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