암호화 저장은 파일 바이트와 복호화 권한을 분리하지만 수신자, 메타데이터, 로컬 사본은 여전히 위협 모델에 포함됩니다.
종단간 암호화된 첨부 파일은 서버에 평문 파일을 제공하지 않고 저장할 수 있습니다. 일반적인 설계는 발신자 기기에서 새로운 콘텐츠 키로 파일을 암호화하고 암호문을 업로드한 뒤, 인증된 암호화 메시지 안에 키를 담아 의도한 수신자에게 보냅니다.
이 분리는 유용하지만 “영지식 저장”은 완전한 명세가 아닙니다. 키, 파일 참조, 파일 이름, 접근 제어, 다운로드된 사본을 어떻게 처리하는지 여전히 물어야 합니다.
첨부 파일의 수명 주기
- 파일 준비. 발신자가 사진, 동영상 또는 문서를 선택합니다. 메타데이터 제거와 변환은 별도 단계입니다. 암호화만으로 EXIF나 문서 속성이 제거되지는 않습니다.
- 암호화 재료 생성. 안전한 구현은 선택한 방식에 따라 필요한 키와 nonce를 생성합니다.
- 업로드 전 암호화. 저장 서비스는 원본 콘텐츠가 아닌 암호화된 바이트를 받습니다.
- 인증된 참조 전달. 암호화된 채팅 메시지는 파일 위치, 복호화 키, 관련 무결성 메타데이터 등 수신자에게 필요한 정보를 전달합니다.
- 가져오기와 검증. 수신 클라이언트는 데이터 본체를 가져오고, 결과를 유효한 콘텐츠로 취급하기 전에 인증을 검증합니다.
- 로컬 사본 관리. 표시, 내보내기, 편집 또는 갤러리 저장으로 원래 암호화 저장 경계 밖에 사본이 생길 수 있습니다.
키는 암호화된 봉투 안에 담겨 같은 제공자의 인프라를 통과할 수 있습니다. 이를 “대역 외”라고 부르면 오해를 낳을 수 있습니다. 데이터 본체의 저장과 논리적으로 분리된 것이지, 반드시 독립된 통신 채널로 전달되는 것은 아닙니다.
인증 암호화가 더하는 것
인증 암호화 방식은 기밀성을 보호하고 인증 범위 안의 무단 변경을 탐지합니다. NIST의 GCM 명세는 그러한 구성 중 하나와 요건을 정의합니다. 올바른 키·nonce 처리와 인증 결과 확인은 필수입니다. 인정받는 알고리즘 이름이 모든 구현을 안전하게 만들지는 않습니다.
애플리케이션은 파일을 올바른 메시지와 대화에 결합해야 합니다. 유효한 암호화 데이터 본체라는 사실만으로 이 특정 채팅에 속한다는 증거가 되지는 않습니다. 파일 식별자, 예상 크기, 청크 순서, 첨부 메타데이터에 적절한 인증 설계가 필요합니다.
저장 서비스가 여전히 알 수 있는 것
| 정보 | 콘텐츠 암호화만으로 숨겨지는가? |
|---|---|
| 원본 파일 바이트 | 키가 없는 주체에게 숨기도록 설계됨 |
| 대략적인 암호화 후 크기 | 보통 숨겨지지 않음 |
| 업로드와 다운로드 시점 | 보통 숨겨지지 않음 |
| 파일을 요청하는 계정 | 라우팅 및 접근 제어 설계에 따라 다름 |
| 파일 이름과 설명 | 프로토콜이 이것들도 보호할 때만 가능 |
| 수신자가 저장한 사본 | 아니요. 수신자는 이미 평문에 접근할 수 있음 |
데이터 본체가 암호화되어도 접근 제어는 중요합니다. 원치 않는 다운로드, 악용, 식별자 노출을 제한할 수 있습니다. 암호화는 권한 부여, 보관 정책 또는 가용성을 대신하지 않습니다.
대용량 파일에는 구호 이상의 것이 필요하다
대용량 파일 설계는 데이터를 스트리밍하거나 인증된 청크로 나눌 수 있습니다. 메모리 사용량을 줄일 수 있지만 청크 번호, 최종 길이, 재시도, 잘림 처리를 정의해야 합니다. 성능 수치를 만들어 내거나, 파일을 메시지에 넣으면 반드시 “래칫 상태 비대화”가 발생한다고 주장하지 마세요. 그 결과는 구현에 달려 있습니다.
유용한 시험에는 유효한 파일, 한 바이트 변경, 잘린 다운로드, 순서가 바뀐 청크, 무단 가져오기 시도가 포함됩니다. 이러한 시험은 허가된 테스트 환경에서 민감하지 않은 파일로만 수행하세요. 클라이언트가 무효 데이터를 열기 전에 거부하는지 기록하세요.
Livara가 문서화한 내용
Livara의 보안 페이지는 업로드 전 암호화, 보호된 세션 안에서 전달되는 파일별 무작위 키, 호환되는 비공개 그룹을 포함해 E2EE가 활성화된 대화에서 파일 이름과 설명을 보호하는 방식을 설명합니다. 오래된 비호환 그룹은 명시적으로 이 범위에서 제외됩니다. 보호되는 대화와 공개 방송 채널도 구분합니다. 이는 문서화된 제품 주장이지 이 글에서 새롭게 수행한 구현 감사가 아닙니다.
위협 모델도 수신자나 침해된 기기가 읽을 수 있는 내용을 노출할 수 있음을 인정합니다. 따라서 암호화 저장은 채팅 메시지를 삭제하면 이미지가 모든 기기에서 사라진다고 약속할 수 없습니다.
민감한 파일을 공유하기 전에 물어볼 질문
대화 유형이 E2EE를 지원하는지, 의도한 수신자를 모두 신뢰할 수 있는지, 파일 자체에 식별 가능한 메타데이터가 있는지 확인하세요. 갤러리 자동 저장과 클라우드 사진 백업은 별도로 검토하세요. 문서는 보내기 전에 댓글, 수정 이력, 내장 속성을 제거해야 하는지 고려하세요.
마지막으로 삭제와 복구를 이해하세요. 서버 데이터 본체를 제거하면 이후 다운로드를 막을 수 있지만 수신자가 이미 가진 사본을 회수할 수는 없습니다. 필요한 키를 잃으면 암호화 파일이 남아 있어도 읽을 수 없게 될 수 있습니다. 좋은 첨부 파일 설계는 두 결과를 모두 명확히 설명합니다.
