부록: 클레임 ID 색인(단일 기준 문서)
이 부록은 백서에 포함된 모든 클레임 ID의 단일 기준 문서입니다. 각 주장에는 고유하고 안정적인 식별자와 앵커가 있으며, 진술(Statement)과 증거(Evidence)를 한 줄로 묶어 제시합니다. 증거는 반복해서 검증할 수 있는 신뢰할 수 있는 참조(장 앵커 또는 상태 페이지/제3자 보고서 진입점)로만 연결되며, 스크린샷이나 재호스팅된 콘텐츠로는 연결하지 않습니다.
유지 관리 규칙
- MUST: 클레임 ID는 고유하고 안정적이어야 하며, 한 번 공개한 ID는 다시 사용하지 않습니다.
- MUST: 각 주장의 증거는 반복해서 검증할 수 있어야 합니다(장 앵커 또는 신뢰할 수 있는 제3자 진입점).
- MUST: 진술은 증거가 뒷받침하는 내용만 주장해야 하며, “절대적인 보안”과 같은 표현은 피합니다.
- SHOULD: 구현이나 정책이 바뀌어 어떤 주장에 영향을 주면 변경 내역에 기록하고, 영향을 받는 클레임 ID를 연결합니다.
1~4장(범위, 위협 모델, 아키텍처, 인가)
SCOPE-01
진술: 이 문서는 범위 안의 위험과 범위 밖의 위험, 그리고 시스템의 보안 경계를 명확하게 정의합니다. 증거:1.3， 1.4
THREAT-01
진술: 위협 모델은 네트워크 공격, 무단 다운로드, 스토리지/서버 측의 읽기 시도, 브라우저 측 공격자를 다룹니다. 증거:2.2
BOUNDARY-01
진술: 신뢰 경계는 클라이언트, 서버, 오브젝트 스토리지, 외부 환경 사이의 책임을 명확히 구분하며, 서버는 CEK를 획득해서는 안 됩니다. 증거:2.4
FAILCLOSE-01
진술: 인증에 실패하거나 컨텍스트가 일치하지 않으면 시스템은 실패 시 차단(fail closed) 방식으로 동작해야 하며, 부분적인 평문도 출력해서는 안 됩니다. 증거:2.5
ARCH-01
진술: 핵심 데이터 객체가 명확하게 분리되어 있습니다. 암호화된 청크, 매니페스트, 감사 데이터는 서로 격리됩니다. 증거:3.2
FLOW-UP-01
진술: 업로드 흐름에는 transferId 생성과, 범위와 만료를 엄격히 제어하는 단기 액세스 토큰(조회 기반 세션 토큰) 발급이 포함됩니다. 증거:3.3
FLOW-DL-01
진술: 다운로드 시에는 URL 프래그먼트를 파싱하여 CEK를 얻으며, 매니페스트 읽기와 청크 읽기에는 서로 다른 범위의 토큰을 사용하고, 인증에 실패하면 차단(fail closed)합니다. 증거:3.4， 2.5
AUTH-TOKEN-01
진술: 단기 액세스 토큰은 만료되는 서버 측 세션 토큰(조회 기반)이며, 암호문과 매니페스트에 대한 접근 제어에 사용됩니다. 증거:4.2
AUTH-SCOPE-01
진술: 토큰은 read_manifest / read_chunk / upload_chunk 같은 범위(scope)별로 분리되며 엄격하게 검증됩니다. 증거:4.3， 4.4， 3.4
AUTH-PAID-01
진술: 유료 사용자는 일회용 매직 링크로 로그인하고, 발신자 측 관리 작업에 사용할 장기 유효 토큰을 클라이언트가 보관하게 됩니다. 증거:4.1， 3.5
REVOKE-01
진술: 발신자는 접근 권한을 회수할 수 있습니다. 전송을 삭제하거나 파일을 제거하면 다운로드가 조기에 무효화되고 이후의 접근이 거부됩니다. 증거:4.5
AUDIT-01
진술: 다운로드 횟수와 진행률 같은 감사 데이터는 발신자에게만 보이며 수신자에게는 보이지 않습니다. 증거:4.6， 3.5
LOG-01
진술: 클라이언트와 서버의 로그/텔레메트리에는 CEK, URL 프래그먼트, 또는 키 자료를 유추할 수 있는 어떤 정보도 포함되지 않습니다. 증거:4.7， 10.2
5장(암호화 및 키 관리)
CRYPTO-ZK-01
진술: CEK는 브라우저에서만 생성되어 URL 프래그먼트를 통해 전달되며, 서버는 CEK가 포함된 전체 다운로드 링크를 생성하지 않습니다. 증거:5.3.1， 5.3.2
CRYPTO-ZK-02
진술: 서버는 CEK를 수신, 저장, 기록하지 않으며, 오브젝트 스토리지에는 암호화된 청크만 저장됩니다. 증거:5.0， 5.5.1
CRYPTO-E2EE-01
진술: 청크에는 AES-128-GCM을 사용하며, 인증에 실패하면 차단(fail closed)해야 하고 부분적인 평문도 출력해서는 안 됩니다. 증거:5.4.2， 5.8.4
CRYPTO-CHUNK-01
CRYPTO-NONCE-01
진술: IV는 noncePrefix(8B)||uint32_be(chunkIndex)로 도출하며, 같은 CEK에서는 반복되어서는 안 됩니다. 증거:5.4.3， 5.8.1
CRYPTO-AAD-01
진술: AAD는 transferId + fileId + chunkIndex에 바인딩되며 EncodeAAD_v1로 인코딩됩니다. 증거:5.4.4
CRYPTO-CLIENT-01
진술: 다운로드/복호화 페이지는 서드파티 스크립트를 로드하지 않으며, 클라이언트 로그/텔레메트리에는 프래그먼트나 키 자료가 포함되지 않습니다. 증거:5.6， 10.2
CRYPTO-TLS-01
진술: 사이트 전체에 HTTPS가 적용되며, TLS 구성은 공개된 제3자 보고서로 검증할 수 있습니다. 증거:5.1.2， /status#tls-configuration
6~7장(데이터 수명 주기 / 악용 방어)
LIFECYCLE-01
진술: 만료와 사용자가 직접 요청한 삭제가 정리 작업을 일으키며, 다운로드를 조기에 무효화하는 회수 기능을 지원합니다. 증거:6.2， 6.3， 4.5
ABUSE-01
진술: 악용 방어는 요청 속도 제한과 단계별 제어를 사용하며, 영지식 경계를 깨지 않고 동작합니다. 증거:7.2， 7.4
8~9장(개인정보 보호 / 웹 보안 및 격리)
PRIVACY-01
진술: 영지식의 정의와 약속이 명시되어 있습니다. CEK는 클라이언트에서만 생성되어 사용되며, 서버는 키를 복구할 수 없습니다. 증거:8.1
PRIVACY-02
진술: URL 프래그먼트가 개인정보에 미치는 영향(복사/붙여넣기, 리퍼러 유출, 로깅)과 그 완화 방안이 문서화되어 있습니다. 증거:8.2， 10.2
WEB-01
진술: 주요 페이지에는 엄격한 CSP와 리소스 경계를 적용하여 삽입 공격과 클릭재킹의 위험을 줄입니다. 증거:9.1， 9.3
WEB-HEADERS-01
진술: 보안 헤더의 기준 수준은 공개된 제3자 보고서로 검증할 수 있습니다. 증거:/status#security-headers
WEB-OBS-01
진술: 이 사이트는 공개된 제3자 모범 사례 스캔으로 점검할 수 있습니다. 증거:/status#http-observatory
10~12장(로깅 및 사고 대응 / 취약점 공개 / 증거)
OBS-01
진술: 관측 가능성은 최소 수집 원칙을 따라 운영 및 보안에 필요한 범위만 다루며, 집계/샘플링 방식을 사용합니다. 증거:10.1
IR-01
진술: 보안 사고 대응 절차(심각도 분류, 격리, 사후 분석, 시정 조치, 공개 공지)가 정의되어 있습니다. 증거:10.4
VDP-01
진술: 취약점 공개 절차가 마련되어 있으며, 영지식 경계에 영향을 줄 수 있는 문제를 우선 처리합니다. 증거:11.2
EV-01
진술: 상태 페이지는 제3자 증거의 진입점을 한곳에 모아 제공하며, 증거는 신뢰할 수 있는 출처로 연결되고 적용 범위의 한계를 명확히 밝힙니다. 증거:12.2， 12.6