PikPak Vault 출시 예정: 종단 간 암호화로 사적인 파일을 보호합니다

PikPak의 새로운 보안 기능인 Vault가 현재 시스템 테스트 단계에 들어갔으며, 모바일 앱부터 단계적인 그레이 롤아웃을 시작할 예정입니다.

이는 단순히 “잠금”을 거는 폴더가 아닙니다. 많은 클라우드 드라이브 제품의 금고, 비공개 공간, 또는 유사 기능과 달리 PikPak Vault는 자동 잠금, 생체 인증 같은 로컬 보안 보호에 더해, 새롭게 설계한 종단 간 암호화 메커니즘, 즉 흔히 영지식 암호화 저장소(Zero-Knowledge Encrypted Storage)라고 부르는 보안 아키텍처를 제공합니다.

이는 여러분의 암호화 키가 오직 여러분의 통제 안에 있다는 뜻입니다. PikPak조차도 Vault에 저장된 파일 내용을 직접 읽거나, 복호화하거나, 확인할 수 없습니다. 매우 사적인 자료, 중요한 문서, 개인적인 컬렉션을 보관하고 싶은 사용자에게 이는 현재 저희가 제공할 수 있는 가장 높은 수준의 보안 보호 중 하나입니다.

이 기능을 구현하기 위해 저희는 여러 달 동안 종단 간 암호화, 키 관리, 다중 기기 동기화, 사용자 경험 사이의 균형을 반복해서 연구했습니다. 또한 보안성, 신뢰성, 사용 편의성을 기준으로 각각의 기술 선택을 신중히 검토하고 전체 설계와 개발을 진행했습니다. 클라우드 드라이브에서 진짜 어려운 점은 단순히 파일을 암호화하는 것이 아니라, 암호화 이후에도 동기화, 공유, 내 드라이브로 저장, 재생, 이어받기 전송을 계속 사용할 수 있게 만드는 것입니다.

이제 이 설계를 기술팀의 관점에서 하나씩 풀어보겠습니다. 먼저 가장 중요한 질문부터 시작합니다. 파일이 Vault에 들어간 뒤 평문은 어디에서 멈추고, 클라우드는 실제로 무엇을 볼 수 있을까요? 이 경계가 분명해야 뒤이어 나오는 키 파생, 파일 암호화, 공유와 저장, 스트리밍 재생 설계를 자연스럽게 이해할 수 있습니다.

1. 종단 간 암호화 경계

Vault가 가장 먼저 하는 일은 파일을 “이해할 수 있는” 능력을 사용자의 기기 안에 남겨두는 것입니다. 파일 내용, 파일 속성, 키 자료는 먼저 로컬에서 암호화된 뒤 클라우드 저장, 동기화, 전송 흐름으로 넘어갑니다. 제품 흐름으로 보면 여전히 익숙한 클라우드 드라이브처럼 동작합니다. 애플리케이션 진입점에서 사용자 공간으로 들어가고, 다시 Vault 또는 공유 공간으로 이어집니다. 다만 암호문을 평문으로 되돌릴 수 있는 능력은 인증된 클라이언트에만 남습니다.

서버는 여전히 파일 저장, 동기화 상태, 공유 인덱스, 전송 오케스트레이션을 담당합니다. 서버가 보고 저장할 수 있는 주요 데이터는 다음과 같습니다.

• 암호화된 파일 내용, 즉 암호문 청크.
• 암호화된 메타데이터. 예를 들어 암호화된 파일 속성, 암호화된 파일 키, 암호화된 청크 설명 정보가 있습니다.
• 계정 또는 공유와 관련된 암호화된 마스터 키 자료, 공유 식별자, 필요한 인덱스.

서버가 직접 보유할 필요가 없는 데이터는 다음과 같습니다.

• 평문 파일 내용.
• 평문 마스터 키.
• 평문 File Key.
• 파일을 직접 복호화할 수 있는 완전한 키 경로.

이 경계는 Vault 전체 설계의 출발점입니다. 클라우드는 파일을 안정적으로 저장하고 동기화하며 사용할 수 있게 만들고, 평문 복원 능력은 인증된 클라이언트 안에 단단히 제한됩니다.

2. 보안 목표와 설계 대응

보안 설계는 알고리즘 이름만 길게 나열한다고 완성되지 않습니다. Vault에서 더 중요한 질문은 각 보안 목표가 시스템 안의 어느 위치에 놓이는지입니다. 어떤 단계가 기밀성을 지키고, 어떤 단계가 변조를 거부하며, 어떤 단계가 키 노출 범위를 줄이는지 명확해야 합니다. 아래 표는 이 목표들을 실제 엔지니어링 위치와 연결한 것입니다.

보안 목표	구현 요점
기밀성	파일 내용은 AES-256-GCM을 사용합니다. 각 파일은 독립적인 File Key를 가지며, 마스터 키 자료는 암호화된 상태로 클라우드에 저장됩니다.
무결성	GCM 인증 태그를 암호문 청크별로 검증하며, 검증 실패 시 평문을 출력하지 않습니다.
키 분리	마스터 키, 메타데이터 키, File Key, Share Key를 다층 파생으로 분리합니다.
노출 최소화	공유에는 독립적인 Share Key를 사용하고, 저장 시 수신자 계정의 키 체계로 다시 포장합니다.
신원 확인과 변조 방지	Ed25519 서명과 검증을 사용해 관련 비즈니스 메시지의 신원을 확인할 수 있습니다.
로컬 접근 제어	로컬 재생에는 임의 접근 토큰을 사용하여 같은 기기의 다른 프로세스가 평문 스트림을 임의로 가져갈 위험을 줄입니다.
진화 가능성	키 파생 라벨과 암호화 스위트 정보에 버전을 포함해 향후 업그레이드에 대비합니다.

3. 다층 키 파생

하나의 마스터 키로 모든 파일을 처리하면 구현은 단순해 보일 수 있지만, 실수의 영향도 함께 커집니다. Vault는 대신 트리형 키 파생 모델을 사용해 계정, 메타데이터, 파일 내용, 공유 컨텍스트를 분리하고, 각 키가 자기 역할에만 묶이도록 합니다.

개념적으로는 용도 라벨과 버전 라벨을 가진 키 트리에 가깝습니다.

사용자 자격 증명(Vault Passcode / 12단어 니모닉) + 클라이언트 측 임의 요소
  -> PBKDF2 또는 니모닉 복구
  -> 마스터 키
  -> 목적 라벨과 버전 라벨을 포함한 HKDF
  -> 파일 도메인 루트 자료
  -> 파일 식별자 기반 파일 메타데이터 키
  -> 파일 속성, File Key, 청크 설명 정보 암호화

Share Key는 별도의 가지처럼 공유 컨텍스트에서 파생됩니다. 공유 워크플로 전용으로 사용되며 일반 파일 암호화 경로와 분리됩니다.

이렇게 분리하면 몇 가지 실질적인 엔지니어링 장점이 생깁니다.

• 용도 분리: 서로 다른 파생 라벨이 키 자료를 서로 다른 보안 컨텍스트에 묶습니다.
• 영향 범위 축소: 하나의 File Key가 노출되어도 다른 File Key를 자연스럽게 도출하기 어렵습니다.
• 버전 기반 진화: 파생 라벨에 버전 정보를 포함해 향후 암호화 스위트 업그레이드를 다루기 쉽게 합니다.
• 계정 복구 지원: 클라우드에는 평문 마스터 키가 아니라 암호화된 마스터 키 자료가 저장됩니다.
• 통합 진입점: 사용자가 Vault를 설정하거나 잠금 해제한 뒤에는 업로드, 다운로드, 공유, 내 드라이브로 저장이 같은 파생 규칙을 재사용할 수 있어 각 비즈니스 흐름이 암호화 세부 사항을 반복 구현할 필요가 없습니다.

암호화 기반은 처음부터 새로 만드는 대신 OpenSSL 등의 성숙한 구성 요소를 바탕으로 구성했습니다. PBKDF2, HKDF, AES-256-GCM, Ed25519를 사용하며, 무작위 원천 품질에 더 민감한 환경에서는 필요에 따라 난수 생성기에 추가 엔트로피를 주입할 수 있습니다.

4. 파일 암호화와 메타데이터 보호

파일 암호화는 Vault의 핵심 데이터 경로입니다. 클라이언트가 파일을 받으면 먼저 고유한 파일 식별자와 해당 파일 전용 File Key를 생성합니다. 이후 파일 메타데이터 키가 File Key를 포장해 클라우드에 저장 가능한 암호화 파일 키를 만들고, 평문 길이, 암호화 스위트 버전, 청크 크기, 암호문 오프셋 등을 포함하는 청크 설명 정보를 기록합니다. 마지막으로 로컬 파일을 청크 단위로 읽어 AES-GCM 암호문과 인증 태그를 출력합니다.

이 과정은 다소 낮은 수준의 처리처럼 보이지만 목적은 분명합니다. 각 파일은 자기 File Key를 가지고, 각 청크는 자기 인증 결과를 가지며, 클라우드는 저장과 동기화가 가능한 암호문을 받지만 직접 읽을 수 있는 파일은 받지 않습니다. 청크 크기는 파일 크기에 따라 대략 64 KB에서 4 MB 범위에서 적응적으로 선택됩니다. 작은 파일은 메타데이터와 스케줄링 오버헤드를 줄이고, 큰 파일은 암호화 호출 횟수를 줄여 처리량을 높입니다. 청크 설명 정보는 Protocol Buffers 같은 구조화된 바이너리 형식으로 직렬화할 수 있어, 버전과 플랫폼을 넘나드는 파싱 일관성을 유지하기 쉽습니다.

Vault가 보호하는 대상은 파일 본문만이 아닙니다. 표시 파일 이름, 디렉터리 구조 관련 필드, 제품에서 사용하는 파일 속성, File Key의 포장 결과, 청크 설명 정보도 보호 대상에 포함될 수 있습니다. 파일 본문이 암호화되어 있더라도 메타데이터는 콘텐츠 유형이나 사용 패턴을 드러낼 수 있으므로, 메타데이터 암호화는 선택 기능이 아니라 종단 간 암호화 모델의 일부로 취급됩니다.

Nonce의 중복을 피하는 것도 의도적으로 처리해야 하는 세부 사항입니다. Vault는 외부 Nonce를 무작정 재사용하지 않고, 파일 식별자와 청크 번호를 함께 사용해 각 청크의 Nonce를 파생합니다. 이를 통해 청크와 파일 사이의 암호화 컨텍스트를 분리하고 GCM이 요구하는 Nonce 유일성을 만족시킵니다.

5. 암호화 공유와 내 드라이브로 저장

암호화 공유가 해결해야 하는 문제는 일반적인 클라우드 공유보다 좁고 구체적입니다. 수신자는 허용된 파일을 읽을 수 있어야 하지만, 공유자의 계정 마스터 키를 받아서는 안 됩니다. PikPak은 공유를 독립적인 암호화 컨텍스트로 다룹니다. 공유자가 공유를 생성하고 공유 식별자를 얻으면, 클라이언트는 해당 컨텍스트의 Share Key를 파생하고 별도의 안전한 채널을 통해 수신자에게 전달합니다. 이후 공유 파일에 필요한 키 자료는 Share Key로 다시 포장되고, 서버에는 공유 인덱스, 암호화된 키 자료, 암호문 파일만 저장됩니다.

수신자가 공유 공간에 들어간다는 것은 서버에서 범용 복호화 키를 받아오는 것이 아니라, 허용된 콘텐츠를 로컬에서 복호화한다는 뜻입니다. 수신자가 공유 파일을 자신의 Vault에 저장하면 클라이언트는 한 번 더 키 재포장을 수행합니다. 공유 컨텍스트 안에서 필요한 파일 키 자료를 해석한 뒤, 수신자 계정의 메타데이터 키로 File Key와 파일 속성을 다시 암호화하고, 새로운 암호화 파일 키와 암호화 파일 속성을 수신자의 클라우드 공간에 저장합니다. 재포장 후 파일은 수신자 자신의 키 계층에 속하며, 원래 공유자의 계정 키 경로에 의존하지 않습니다.

6. 스트리밍 복호화와 Range 접근

대용량 파일, 영상, 오디오에서는 전체 객체를 다운로드한 뒤 복호화하는 방식이 비효율적입니다. 따라서 Vault는 평문 범위에서 암호문 범위로의 매핑을 지원합니다. 상위 계층이 특정 평문 바이트 범위를 요청하면, 클라이언트는 청크 설명 정보를 사용해 대응되는 암호문 범위를 계산하고, 필요한 암호문만 가져와 로컬에서 인증 태그를 검증하고 복호화합니다.

이 Range 매핑 덕분에 암호화 상태에서도 이어받기 전송과 탐색 재생이 가능합니다. 다운로드와 업로드는 원격에서 확인된 진행률에 맞출 수 있고, 플레이어의 위치 이동은 전체 파일 재시작이 아니라 새로운 Range 요청으로 처리됩니다. 큰 파일 전체를 한 번에 메모리에 올릴 필요도 없습니다. 로컬 재생에서는 클라이언트가 127.0.0.1에서 가벼운 HTTP 복호화 프록시를 시작할 수 있습니다. 시스템 플레이어는 표준 HTTP Range 요청을 그대로 사용하지만, 암호문 위치 확인, GCM 검증, 복호화는 로컬 클라이언트 안에 남습니다. 재생 주소에는 로컬 접근 토큰이 포함되어 평문 스트림의 범위를 현재 재생 세션으로 제한합니다.

다운로드 경로도 같은 원칙을 따릅니다. 클라이언트는 목표 평문 구간에 필요한 암호문 범위만 요청하고, 수신과 동시에 검증 및 복호화를 진행하며, 작업이 종료되거나 취소되면 임시 데이터를 해제합니다. 재생 경로에서는 세션 큐와 전송 버퍼 상한을 통해 복호화와 출력 속도를 조절하여, 복호화가 소비 속도보다 빠를 때 메모리 사용량이 과도하게 증가하는 것을 피합니다.

7. 업로드 측 청크 암호화와 진행률 동기화

업로드는 다운로드와 완전히 다른 모델을 도입하지 않고, 같은 청크 구조를 반대 방향으로 사용합니다. 클라이언트는 먼저 원격에서 수신 및 확인된 바이트 수를 조회하고, 정렬된 오프셋에서 암호문 생성을 재개한 뒤 암호문 청크를 점진적으로 업로드합니다. 서버는 전송 스케줄링과 진행률 확인만 담당하면 되므로, 평문 내용을 이해하지 않아도 원격 진행률 조회, 계속 업로드, 완료 확인을 하나의 상태 머신으로 연결할 수 있습니다.

이 방식은 업로드를 하나의 큰 요청이 아니라 이어갈 수 있는 흐름으로 만듭니다. 일시 중지, 재개, 취소, 진행률 조회가 가능하고, 사용자 관점에서는 스트리밍 다운로드와 대칭적인 경험을 제공합니다. 시스템 관점에서는 전체 파일을 한 번에 업로드 버퍼에 밀어 넣지 않아도 됩니다.

8. 크로스 플랫폼 구현

Vault는 C++ 코어 라이브러리와 C 인터페이스를 중심으로 구축됩니다. 이를 통해 동일한 암호화 로직과 데이터 형식 처리를 여러 클라이언트에서 재사용할 수 있고, 플랫폼마다 별도의 암호화 구현을 반복 작성하지 않아도 됩니다. 대상 환경은 iOS, Android, macOS, Windows, Linux, 최신 브라우저를 포함합니다. 공유 코어의 가치는 단순히 더 많은 기기를 지원하는 데 있지 않고, 동일한 암호화 데이터가 어떤 기기에서도 동일한 키 파생, 청크 설명 파싱, Nonce 파생, 인증 검증, 복호화 흐름을 따르게 하는 데 있습니다.

9. 일반적인 생명주기

사용자 흐름 관점에서 생명주기는 비교적 명확합니다. 사용자가 Vault를 설정하거나 잠금 해제할 때, 클라이언트는 사용자 자격 증명 또는 12단어 니모닉을 받고, PBKDF2 또는 니모닉 복구를 통해 마스터 키 자료를 복원한 뒤, 클라우드에 저장된 암호화된 마스터 키 자료를 해제합니다. 그다음 파일 도메인, 공유 도메인, 서명 도메인 등의 파생 컨텍스트를 초기화하고, 이후 업로드, 다운로드, 공유, 내 드라이브로 저장은 같은 파생 모델을 재사용합니다.

파일 업로드 시에는 클라이언트가 파일 식별자와 File Key를 만들고, 파일 크기에 따라 청크 전략을 선택한 뒤 청크 설명 정보를 생성하고 암호화합니다. 파일 본문은 청크 단위로 암호화되어 각 청크마다 암호문과 GCM 인증 태그를 만들고, 클라이언트는 암호문 청크, 암호화 파일 키, 암호화 파일 속성, 암호화 청크 설명 정보를 함께 업로드합니다. 서버는 수신 및 커밋된 진행률만 확인하면 됩니다.

다운로드와 재생은 반대 방향으로 동작합니다. 클라이언트는 파일 속성, File Key, 청크 설명 정보를 먼저 복호화합니다. 전체 다운로드라면 암호문 청크를 순서대로 가져와 복호화하고, Range 재생이라면 평문 범위를 암호문 범위로 먼저 매핑한 뒤 필요한 암호문만 가져와 청크별 GCM 태그를 검증합니다. 검증을 통과한 뒤에만 평문을 출력하며, 검증 실패 시에는 출력하지 않습니다.

암호화 공유와 내 드라이브로 저장도 같은 경계를 따릅니다. 공유자가 공유를 생성하면 클라이언트는 Share Key를 파생하고 공유 파일에 필요한 키 자료를 포장합니다. 수신자는 공유 공간 안에서 허용된 콘텐츠를 로컬에서 복호화합니다. 수신자가 파일을 저장하면, 클라이언트는 File Key와 파일 속성을 수신자 자신의 메타데이터 키로 다시 포장해 저장된 파일이 수신자 자신의 키 계층에 포함되도록 합니다.

10. 구현 시 주의사항

이런 설계의 위험은 단일 알고리즘보다 경계가 깨지는 데서 더 자주 발생합니다. Nonce는 반복되면 안 되므로 청크 번호, 파일 식별자, 스위트 버전이 함께 컨텍스트 유일성을 보장해야 합니다. GCM 검증 실패는 반드시 실패로 처리해야 하며, 경고나 허용 읽기로 낮춰서는 안 됩니다. 메타데이터 암호화는 파일명만이 아니라 청크 설명 정보와 포장된 File Key까지 포함해야 합니다. 공유는 계정 마스터 키를 노출해서는 안 되며, 내 드라이브로 저장할 때도 공유자의 포장 결과를 그대로 재사용해서는 안 됩니다. 로컬 HTTP 복호화 프록시는 파일과 공간 컨텍스트에 묶인 단기 임의 접근 토큰을 사용해야 합니다. 파생 라벨, 암호화 스위트, 데이터 형식은 모두 버전 정보를 포함해 과거 데이터와의 충돌을 피해야 합니다. 크로스 플랫폼 구현은 키 파생, 청크 설명 파싱, Nonce 파생, GCM 검증, Range 매핑에 대해 같은 테스트 벡터를 공유해야 합니다.

요약

PikPak Vault는 일반 클라우드 파일 위에 단순히 패스코드 계층을 추가한 기능이 아닙니다. 파일 저장, 키 관리, 공유, 내 드라이브로 저장, 스트리밍 접근을 종단 간 암호화를 중심으로 다시 설계한 구조입니다.

이 설계의 핵심은 특정 암호화 알고리즘을 홍보 문구로 만드는 것이 아니라, 클라이언트 측 암호화, 키 분리, 메타데이터 보호, 암호화 공유와 내 드라이브로 저장, Range 재생, 크로스 플랫폼 일관성을 하나의 엔지니어링 경로로 연결하는 데 있습니다. 파일은 클라이언트에서 암호화되고 클라우드는 암호문을 처리합니다. 마스터 키, 메타데이터 키, File Key, Share Key는 다층 파생으로 분리됩니다. 파일 본문과 일부 메타데이터는 함께 보호 모델에 포함됩니다. 암호화 공유와 내 드라이브로 저장은 키 재포장을 통해 계정 키 노출을 줄이고, Range 매핑과 로컬 복호화 프록시는 대용량 파일 재생과 이어받기 전송을 계속 사용할 수 있게 합니다. 크로스 플랫폼 코어는 여러 기기에서 같은 보안 의미와 동작을 유지합니다. 클라우드 저장소 제품에서는 보안과 사용성이 함께 성립해야 하며, Vault는 이 균형을 실현 가능하고 확장 가능한 형태로 만들기 위한 기술 설계입니다.