종단간 암호화란 무엇인가? 사진을 보호하는 방식
종단간 암호화는 읽을 수 있는 사진 콘텐츠와 평문 콘텐츠 키를 저장소 제공업체가 갖지 못하게 합니다.
종단간 암호화(E2EE)는 승인된 한쪽 단말에서 평문을 암호화하고 다른 승인된 단말에서 복호화하는 보안 모델입니다. 저장 또는 전송을 맡은 제공업체는 평문 콘텐츠 키를 보유하지 않습니다. 이 경계는 서버 측에서 콘텐츠를 직접 읽는 것을 막아 줍니다. 그러나 모든 메타데이터를 숨기지는 못하며, 손상된 단말, 복구 자격 증명, 공유 받은 사람, 악의적인 클라이언트 업데이트로부터 보호하지도 못합니다.
사진 저장소에서 종단간 암호화란 휴대폰이 업로드 전에 사진 내용을 암호화하고, 클라우드는 읽을 수 있는 이미지가 아닌 암호문을 저장한다는 뜻입니다. 복호화하려면 승인된 기기나 복구 경로를 통해 얻을 수 있는 키가 필요합니다. 파일 크기, 시점, 계정 데이터, 공유 관계 등의 메타데이터는 여전히 보일 수 있습니다. 이 가이드는 그 경계를 설명하고 일반적인 서비스 모델을 비교합니다.
종단간 암호화의 작동 방식
핵심 메커니즘은 키 생성, 암호화, 복호화의 세 단계로 이루어집니다.
키 생성
사용자의 기기가 암호 키를 생성합니다. 대칭 암호화(AES-256 등)에서는 같은 키로 암호화와 복호화를 합니다. 비대칭 암호화(RSA 등)에서는 공개 키로 암호화하고 개인 키로 복호화합니다. 많은 종단간 암호화 시스템은 두 방식을 결합합니다. 비대칭 암호화로 대칭 세션 키를 교환하고, 그 세션 키가 대량의 데이터 암호화를 처리합니다.
사진 금고 앱은 여러 가지 키 관리 설계를 사용합니다. 어떤 앱은 비밀번호에서 파일 키를 직접 도출합니다. 더 강력한 계층형 설계에서는 자격 증명에서 도출한 잠금 해제 키로 무작위 파일 키를 감쌀 수 있습니다. Vaultaire는 PBKDF2-HMAC-SHA512를 사용해 5x5 패턴과 기기 전체 솔트에서 256비트 금고 키를 도출합니다. 이 금고 키는 암호화된 색인을 인증하고, 파일 암호화에 쓰이는 별도의 무작위 마스터 키를 풀어냅니다.
암호화
평문(사진)은 암호화 키와 암호화 알고리즘을 통해 암호문으로 변환됩니다. 이 용도로 가장 널리 쓰이는 대칭 암호는 AES-256-GCM입니다. GCM(Galois/Counter Mode)은 인증된 암호화를 제공합니다. 데이터를 암호화하는 동시에 변조를 감지하는 인증 태그를 생성합니다. 각 파일은 고유한 초기화 벡터(IV)를 받으므로, 동일한 파일이라도 서로 다른 암호문이 생성됩니다.
복호화
받는 쪽 기기는 같은 키(대칭) 또는 짝이 되는 개인 키(비대칭)를 사용해 변환을 되돌립니다. 올바른 키가 없으면 암호문은 무작위 데이터와 구별할 수 없습니다. 수학적 지름길은 없습니다. AES-256의 가능한 키는 2^256개로, 관측 가능한 우주의 추정 원자 수보다 많습니다.
종단간 암호화와 다른 암호화 모델 비교
모든 암호화가 종단간 암호화인 것은 아닙니다. 그 차이가 누가 데이터에 접근할 수 있는지를 결정합니다.
전송 중 암호화(TLS/SSL)
데이터는 기기와 서버 사이에서 암호화됩니다. 서버는 데이터를 받으면 복호화합니다. 전송 중 도청은 막아 주지만, 서버에서는 데이터를 읽을 수 있는 상태로 남깁니다. 모든 주요 클라우드 서비스가 전송 중 암호화를 사용합니다. 이는 최소한의 기본일 뿐, 충분한 기준은 아닙니다.
저장 데이터 암호화(서버 측)
서버가 자체 관리하는 키로 저장된 데이터를 암호화합니다. 서버 하드웨어의 물리적 도난은 막아 주지만, 서비스 제공업체, 그 직원, 제공업체를 대상으로 한 법적 요청은 막지 못합니다. iCloud, Google Drive, Dropbox는 모두 서버 측 저장 데이터 암호화를 사용합니다. 키는 제공업체가 보유합니다.
종단간 암호화
데이터는 저장소 제공업체가 받기 전에 승인된 단말에서 암호화됩니다. 제대로 된 설계는 평문 콘텐츠 키를 제공업체의 일상적인 서버 측 보관 범위 밖에 둡니다. 따라서 저장소만 침해되거나 저장된 콘텐츠에 대한 법적 요구가 있어도, 나오는 것은 읽을 수 있는 사진이 아니라 암호문입니다. 제공업체는 여전히 암호문과 메타데이터를 제공하거나, 클라이언트 소프트웨어를 배포하거나, 복구 및 공유 시스템을 운영할 수 있으며, 이 모든 것을 위협 모델에 포함해야 합니다.
| 암호화 모델 | 키 보유자 | 제공업체가 데이터를 읽을 수 있는가? | 제공업체로부터 보호하는가? |
|---|---|---|---|
| 전송 중만(TLS) | 서버 | 예 | 아니요 |
| 저장 시(서버 측) | 서버 | 예 | 아니요 |
| 종단간 | 승인된 단말 또는 복구 수단 보유자 | 저장된 암호문만으로는 불가 | 제공업체가 보유한 저장소 키로부터 콘텐츠를 보호 |
| 제공업체가 볼 수 없는 클라이언트 측 암호화 | 클라이언트와 문서화된 복구 경로 | 설계상 평문 콘텐츠 접근 불가 | 콘텐츠는 보호되지만 메타데이터와 클라이언트 신뢰 문제는 남음 |
사진 저장소 서비스의 암호화 방식
암호화 모델은 사진 저장소 서비스마다 크게 다릅니다. 일부 서비스는 모델을 밝히지 않고 "암호화"를 광고하므로, 사용자는 사진이 종단간 암호화되지 않았는데도 종단간 암호화되었다고 오해할 수 있습니다.
iCloud 사진
Apple은 전송 중 암호화와 저장 데이터 암호화를 사용합니다. 기본적으로 암호화 키는 Apple이 보유합니다. 유효한 법적 요청이 있으면 Apple은 iCloud 사진 데이터를 제공할 수 있습니다. 예외: 2022년 12월부터 제공되는 Apple의 고급 데이터 보호(ADP)는 iCloud 사진에 종단간 암호화를 추가합니다. ADP는 설정에서 직접 켜야 합니다. 켜면 Apple은 iCloud 사진 데이터에 접근할 수 없습니다. 대부분의 사용자는 ADP를 켜지 않았습니다.
Google 포토
Google은 서버 측 키로 전송 중 암호화와 저장 데이터 암호화를 사용합니다. 잠긴 폴더 콘텐츠를 포함한 모든 Google 포토 데이터의 암호화 키는 Google이 보유합니다. Google은 법적 데이터 요청에 응할 수 있습니다. Google은 Google 포토에 종단간 암호화 옵션을 제공하지 않습니다.
Dropbox
전송 중 암호화(TLS 1.2 이상)와 저장 데이터 암호화(Dropbox가 관리하는 키로 AES-256)를 사용합니다. 키는 Dropbox가 보유하며 파일에 접근할 수 있습니다. Dropbox는 데이터 침해를 겪은 적이 있습니다(2012년, 6,800만 계정). Dropbox Vault(유료 기능)는 PIN 보호를 추가하지만 종단간 암호화는 추가하지 않습니다.
OneDrive
Microsoft는 Microsoft가 관리하는 키로 전송 중 암호화와 저장 데이터 암호화를 사용합니다. 키는 Microsoft가 보유합니다. OneDrive Personal Vault는 본인 확인(2단계 인증)을 추가하지만 종단간 암호화는 추가하지 않으므로, Microsoft는 여전히 데이터에 접근할 수 있습니다. 기업 고객에게는 고객 관리 키가 제공됩니다.
Vaultaire
제공업체가 키를 보유하지 않는 클라이언트 측 암호화. Vaultaire는 클라우드에 업로드하기 전에 기기에서 사진과 메타데이터를 AES-256-GCM으로 암호화합니다. 무작위 마스터 키가 금고 데이터를 암호화합니다. 사용자의 패턴과 기기 솔트에서 도출한 로컬 금고 키가 그 마스터 키를 감싸고, 패턴에서 도출한 별도의 백업 키가 비공개 CloudKit 백업 레코드를 보호합니다. Vaultaire는 콘텐츠 서버를 운영하지 않고 이 키들을 받지도 않으므로, CloudKit 레코드를 평문으로 바꿀 수 없습니다. 앱, iOS, 잠금이 해제된 기기는 여전히 신뢰 경계 안에 있으며, 법적 요청을 통해 해당 제공업체가 보유한 계정 또는 서비스 메타데이터를 얻을 수는 있습니다.
| 서비스 | 전송 중 암호화 | 저장 데이터 암호화 | 종단간 암호화 | 제공업체 접근 가능 |
|---|---|---|---|---|
| iCloud 사진(기본값) | 예 | 예(Apple 키) | 아니요 | 예 |
| iCloud 사진(ADP 켬) | 예 | 예 | 예 | 아니요 |
| Google 포토 | 예 | 예(Google 키) | 아니요 | 예 |
| Dropbox | 예 | 예(Dropbox 키) | 아니요 | 예 |
| OneDrive | 예 | 예(Microsoft 키) | 아니요 | 예 |
| Vaultaire | 예 | 예 | 클라이언트 측 암호화 백업, 기본으로 켜짐 | 평문 콘텐츠 키 없음. CloudKit 메타데이터는 남음 |
사진에 종단간 암호화가 중요한 이유
사진은 특히 민감한 데이터입니다. 얼굴, 위치(GPS 메타데이터), 타임스탬프, 사적인 순간의 시각적 기록이 담겨 있습니다. 사진 보관함이 유출되면 다른 거의 모든 데이터 유형보다 많은 개인 정보가 노출됩니다.
데이터 침해
서비스 제공업체가 서버 측 키로 사진을 저장하는 경우, 저장소와 키 관리 경로가 모두 침해되면 읽을 수 있는 콘텐츠가 노출될 수 있습니다. 제대로 된 종단간 암호화에서는 저장소만 침해되면 암호문과 서비스가 보관하는 메타데이터만 나옵니다. 단말 침해, 도난당한 복구 자격 증명, 악의적인 클라이언트 소프트웨어, 키 서비스 결함은 평문에 이르는 별도의 경로로 남습니다.
법적 접근과 정부 접근
서비스 제공업체는 보유한 기록을 제출하도록 요구받을 수 있습니다. 종단간 암호화에서는 그 기록이 읽을 수 있는 사진 콘텐츠가 아니라 암호문, 계정 정보, 접근 로그, 레코드 크기, 시점, 공유 메타데이터일 수 있습니다. 요구가 기기, 복구 수단, 공유 받은 사람, 향후 클라이언트 동작에까지 미칠 수 있는지는 별개의 법적·기술적 문제입니다.
내부자 접근
제공업체가 관리하는 저장소 키에 접근할 수 있는 직원이나 공격자는 서버 측에서 암호화된 콘텐츠에 도달할 수 있습니다. 제공업체에 평문 콘텐츠 키가 없으면 종단간 암호화가 이 직접적인 저장소 키 경로를 제거합니다. 그러나 제공업체가 클라이언트 배포, 계정 상태, 메타데이터, 공유, 복구 구성 요소를 통제할 수 있으므로, 내부자 악용을 원천적으로 불가능하게 만들지는 못합니다.
메타데이터 보호
일부 종단간 암호화 구현은 파일 내용만 암호화하고 파일 이름과 날짜 같은 메타데이터는 보호하지 않습니다. Vaultaire는 파일 헤더, MIME 유형, 색인, 썸네일 및 기타 금고 메타데이터를 AES-256-GCM 인증 암호화로 보호합니다. 다만 저장된 암호문의 길이와 암호화된 색인 파일의 개수는 앱 컨테이너에 접근할 수 있는 사람에게 구조적 정보를 노출할 수 있습니다.
종단간 암호화에 대한 흔한 오해
"클라우드 저장소가 암호화되어 있으니 사진은 안전하다." 서버 측 암호화는 서버 하드웨어에 대한 외부 침해를 막아 줍니다. 제공업체 자체, 법적 요청, 내부자 위협은 막지 못합니다. 키는 제공업체가 보유합니다.
"HTTPS면 사진이 종단간 암호화된다." HTTPS(TLS)는 기기와 서버 사이에서 전송 중인 데이터를 암호화합니다. 데이터가 서버에 도착하면 복호화됩니다. HTTPS는 데이터를 암호화하는 것이 아니라 통로를 암호화하는 것입니다.
"종단간 암호화면 아무도 내 사진을 볼 수 없다." 종단간 암호화는 키가 없는 사람은 사진을 볼 수 없다는 뜻입니다. 누군가 비밀번호나 키를 가지고 있다면 데이터를 복호화할 수 있습니다. 키 관리와 강력한 비밀번호는 여전히 필수입니다.
"Apple/Google은 내 사진을 볼 수 없다." 기본적으로 두 회사 모두 클라우드에 저장된 사진의 암호화 키를 보유합니다. Apple은 고급 데이터 보호를 선택 옵션으로 제공합니다. Google은 Google 포토에 종단간 암호화 옵션을 전혀 제공하지 않습니다.
Vaultaire의 종단간 암호화 구현 방식
Vaultaire는 계층형 종단간 암호화 방식을 사용합니다.
- AES-256-GCM이 모든 파일 내용을 암호화합니다. 각 파일은 고유한 초기화 벡터를 받습니다. 인증된 암호화가 변조를 감지합니다.
- HMAC-SHA512 기반 PBKDF2가 사용자가 그린 패턴과 기기 솔트에서 로컬 금고 키를 도출합니다. 작업 계수는 패턴에 엔트로피를 더하지는 않지만, 오프라인 추측 한 번당 비용을 높입니다. 이 금고 키는 암호화된 색인을 인증하고, 파일 데이터에 쓰이는 무작위 마스터 키를 풀어냅니다.
- 메타데이터용 AES-256-GCM이 파일 이름, 날짜, 크기, 색인, 썸네일을 인증 암호화로 보호합니다.
- iOS 키체인과 데이터 보호가 기기 솔트와 암호화된 복구 데이터베이스를 보호합니다. 금고가 열려 있는 동안 AES-GCM 연산과 활성 대칭 키는 앱 프로세스 안에 남습니다.
- 제공업체 키 분리란 Wraxle이 평문 금고 키, 마스터 키, 백업 키, 복구 키를 받지 않는다는 뜻입니다. CloudKit 백업(기본으로 켜짐), 동기화, 공유는 암호문 레코드와 암호화된 키 봉투를 저장하며, Apple은 여전히 서비스 메타데이터를 볼 수 있습니다. Vaultaire는 Vaultaire 계정을 요구하지 않습니다.
Vaultaire는 패턴을 포함한 복구 정보를 iOS 키체인에 저장된 AES-GCM 암호화 데이터베이스 안에 보관합니다. 이 정보는 평문 파일로 기록되지 않으며 Vaultaire 계정 서비스로 전송되지도 않습니다. 사용할 수 있는 패턴, 복구 문구, 이미 잠금 해제된 기기가 하나도 남아 있지 않으면, Vaultaire에는 접근을 복원할 수 있는 제공업체 복구 키가 없습니다.
자주 묻는 질문
종단간 암호화는 합법입니까?
암호화, 강제 접근, 암호화 서비스에 대한 법적 취급은 관할권마다 다르며 바뀔 수 있습니다. 이 가이드는 기술 모델을 설명할 뿐 법률 자문이 아닙니다. 국경 검색, 법원 명령, 규제 대상 기록 또는 기타 위험도가 높은 상황이 관련된다면 현재 현지 법률을 확인하십시오.
수사기관이 종단간 암호화를 뚫을 수 있습니까?
공격자가 AES-256 키 공간 전체를 탐색해야 하는 경우는 드뭅니다. 분석관은 약한 비밀번호나 패턴, 잠금이 해제된 단말, 메모리, 복구 문구, 공유 받은 사람, 백업, 구현 결함을 노릴 수 있습니다. 무작위 고엔트로피 키로 올바르게 구현된 AES-256-GCM은 직접적인 키 탐색에 견디도록 설계되었지만, 그것은 시스템의 한 부분일 뿐입니다.
종단간 암호화와 제로 지식 암호화는 어떻게 다릅니까?
종단간 암호화는 평문의 암호화와 복호화가 어디서 이루어지는지, 그리고 사용 가능한 콘텐츠 키를 누가 보유하는지를 설명합니다. "제로 지식"은 제공업체가 볼 수 없는 암호화를 뜻하는 제품 마케팅 용어로 자주 쓰이지만, 문자 그대로 받아들여서는 안 됩니다. 서비스는 평문 키가 없어도 암호문, 계정 데이터, 크기, 시점, 공유 관계 및 기타 메타데이터를 볼 수 있습니다. 명칭만 보지 말고 문서화된 키 경로와 복구 경로를 평가하십시오.
종단간 암호화 때문에 휴대폰이 느려집니까?
최신 기기는 시스템 암호화 라이브러리를 통해 제공되는 하드웨어 가속으로 AES-256을 효율적으로 처리합니다. iPhone에서 Vaultaire는 CryptoKit을 통해 앱 프로세스 안에서 AES-GCM을 수행합니다. Apple의 공개 Secure Enclave API는 파일 암호화를 위한 범용 AES-GCM 엔진이 아닙니다. 암호화와 복호화 부담은 파일 크기와 기기에 따라 다르지만, 일반적인 사용 중에는 방해되지 않도록 설계되었습니다.
암호화 키를 잃어버리면 어떻게 됩니까?
사용 가능한 복호화 경로와 복구 경로를 모두 잃으면 암호화된 데이터는 복구할 수 없습니다. 그래서 많은 종단간 암호화 시스템은 복구 문구, 신뢰할 수 있는 기기, 복구 연락처, 비상 키트, 암호화된 키 봉투를 사용합니다. 이러한 메커니즘은 접근을 유지해 주지만, 각각이 보안 모델의 일부가 되기도 합니다.
결론
업로드 전에 승인된 단말에서 암호화가 이루어지면, 종단간 암호화는 저장소 제공업체의 평문 키 경로를 제거할 수 있습니다. 이는 의미 있는 보호이지만, 시스템 전체에 대한 보증은 아닙니다. 비공개 사진을 서비스에 맡기기 전에 콘텐츠 키 보관, 복구, 메타데이터, 클라이언트 업데이트, 단말 보안, 공유를 확인하십시오.
Vaultaire는 iOS용 클라이언트 측 암호화를 구현합니다. 사진과 금고 메타데이터는 백업이나 동기화 전에 기기에서 AES-256-GCM으로 암호화됩니다. Vaultaire는 복호화 키를 받지 않으며, 암호화된 레코드를 사진으로 바꿀 수 있는 서버도 운영하지 않습니다. 이 제공업체 경계가 손상되었거나 잠금이 해제된 iPhone을 신뢰할 수 있게 만들어 주지는 않습니다.