v0.0
3-Zone 보안 아키텍처 설계서¶
1. Executive Summary¶
본 문서는 D'CENT 엔터프라이즈 콜드월렛 커스터디 솔루션의 3-Zone 보안 아키텍처를 설계한다. 시스템 전체를 Online Zone, Offline App Zone, Hardware SE Zone 3개의 보안 영역으로 분리하고, 각 영역의 보안 경계, 신뢰 수준, 허용 통신 채널, 데이터 보호 수준을 정의한다.
설계 목적: - 개발팀이 각 컴포넌트의 보안 경계와 책임 범위를 명확히 이해 - 컴포넌트 간 독립 구현이 가능한 아키텍처 기반 제공 - Phase 2 AC-ID 제약조건 42개의 아키텍처 수준 충족 보장 - STRIDE 위협 모델(Plan 04)의 Trust Boundary 정의 기반 제공
핵심 원칙: - Zero Trust: 각 Zone은 다른 Zone을 신뢰하지 않음 - Defense in Depth: 3개 Zone이 3중 방어 계층을 형성 - Air-Gap First: Zone 1↔Zone 2 간 통신은 반드시 에어갭(QR)을 경유, Zone 2↔Zone 3은 USB-C 유선 연결 - Hardware Root of Trust: Zone 3(SE)이 유일한 신뢰 루트
2. Zone 정의 및 경계¶
2.1. Zone 1: Online Zone (온라인 대시보드)¶
| 항목 | 정의 |
|---|---|
| 컴포넌트 | 온라인 대시보드 (Web + API + DB + 블록체인 노드) |
| 환경 | 네트워크 연결 환경 (인터넷/인트라넷) |
| 신뢰 수준 | LOW — 네트워크 노출로 인해 침해 가능성 상존 |
| 허용 통신 | HTTPS (사용자), JSON-RPC/gRPC (블록체인 노드), 에어갭 출구(QR 생성) |
| 데이터 보호 | AES-256 암호화 저장, TLS 1.3 전송 암호화 |
| 키 접근 권한 | 없음 — 프라이빗 키에 접근 불가. 공개키와 서명 결과만 보유 |
| AC-ID 해당 | 31개 제약조건 (전체의 74%) |
보안 경계: - 외부(인터넷)와 방화벽/WAF로 분리 - 내부적으로 API Gateway → 서비스 레이어 → 데이터 레이어 계층 분리 - 블록체인 노드는 별도 네트워크 세그먼트에 격리 - Warm Tier MPC-TSS 서버는 내부 네트워크에서만 접근 (별도 VLAN)
위협 노출도: 가장 높음 — 인터넷 연결로 외부 공격 벡터 상존. 따라서 이 Zone에서는 트랜잭션 생성/정책 검증/서명 취합/블록체인 전파만 수행하며, 서명 행위 자체는 절대 수행하지 않는다.
2.2. Zone 2: Offline App Zone (오프라인 서명 앱)¶
| 항목 | 정의 |
|---|---|
| 컴포넌트 | 오프라인 서명 앱 (태블릿/데스크톱) |
| 환경 | 네트워크 완전 차단 (비행기 모드 + MDM 또는 물리적 NIC 제거) |
| 신뢰 수준 | MEDIUM — 네트워크 격리이나 소프트웨어 변조 가능성 존재 |
| 허용 통신 | QR 코드(카메라/화면, 대시보드 방향), USB-C(콜드월렛 방향) |
| 데이터 보호 | 로컬 스토리지 AES-256 암호화, 서명 세션 데이터 24시간 후 자동 삭제 |
| 키 접근 권한 | 없음 — 프라이빗 키에 접근 불가. 서명 요청 중계와 부분 서명 수집만 수행 |
| AC-ID 해당 | 9개 제약조건 |
보안 경계: - 네트워크 스택 완전 비활성화 (WiFi, Bluetooth, 셀룰러 모두 차단) - Zone 1과는 QR로만 데이터 교환 (에어갭 경계 TB-3) - Zone 3과는 USB-C로 데이터 교환 (SE 보안 경계 TB-4) - 앱 무결성 검증 (코드 서명, 앱 해시 확인)
위협 노출도: 중간 — 네트워크 격리로 원격 공격 차단. 그러나 물리적 접근을 통한 앱 변조, 악성 앱 설치 공격 가능. 따라서 이 Zone에서 수행하는 2차 정책 검증은 보조적 역할이며, 최종 신뢰는 Zone 3(SE)에 위임한다.
2.3. Zone 3: Hardware SE Zone (D'CENT X 콜드월렛 SE)¶
| 항목 | 정의 |
|---|---|
| 컴포넌트 | D'CENT X 콜드월렛 내 Secure Element (CC EAL5+) |
| 환경 | 물리적 완전 격리 — 네트워크 스택 자체가 존재하지 않음 |
| 신뢰 수준 | ABSOLUTE — Tamper-resistant 하드웨어, Root of Trust |
| 허용 통신 | USB-C — SE 경유, QR(카메라 입력/화면 출력, 보조) |
| 데이터 보호 | SE 내부 암호화 저장, 물리적 탬퍼 방지, Side-channel 공격 방어 |
| 키 접근 권한 | 독점 — 프라이빗 키 생성, 저장, 서명 모두 SE 내부에서만 수행 |
| AC-ID 해당 | 14개 제약조건 |
보안 경계: - SE 칩 물리적 경계가 보안 경계 (Tamper-resistant packaging) - 네트워크 스택이 존재하지 않으므로 네트워크 공격 원천 차단 - 프라이빗 키는 SE 외부로 추출 불가 (AC-KM-02) - TRNG + DRBG로 키 생성 (AC-KM-01) - SE 내부 정책 엔진이 최종 방어선 (Phase 4 HW Policy Engine)
위협 노출도: 극히 낮음 — 물리적 디바이스 탈취 + SE 물리 공격만이 유일한 공격 벡터. PIN 보호, 오류 횟수 제한, WYSIWYS 검증이 추가 방어.
3. Zone 경계 다이어그램¶
3.1. 전체 아키텍처 구조도¶
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Zone 1: ONLINE ZONE │ │
│ │ Trust Level: LOW │ │
│ │ │ │
│ │ ┌───────────┐ ┌──────────┐ ┌───────────────────┐ │ │
│ │ │ Web UI │ │ API │ │ Blockchain Nodes │ │ │
│ │ │ Dashboard │ │ Gateway │ │ (BTC/ETH/EVM) │ │ │
│ │ └───────────┘ └──────────┘ └───────────────────┘ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌───────────────────┐ │ │
│ │ │ Policy │ │ Event │ │ MPC-TSS Servers │ │ │
│ │ │ Engine │ │ Store │ │ (Warm Tier Only) │ │ │
│ │ └──────────┘ └──────────┘ └───────────────────┘ │ │
│ │ │ │
│ └───────────────────────┬───────────────────────────────┘ │
│ │ │
│ ════════════════════════╪══════════════════ TB-3: Air-Gap Boundary ════ │
│ │ QR (UR Animated) │
│ │ │
│ ┌───────────────────────▼───────────────────────────────┐ │
│ │ Zone 2: OFFLINE APP ZONE │ │
│ │ Trust Level: MEDIUM │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌───────────────────┐ │ │
│ │ │ QR │ │ TX │ │ Signature │ │ │
│ │ │ Scanner │ │ Viewer │ │ Collector │ │ │
│ │ └──────────┘ └──────────┘ └───────────────────┘ │ │
│ │ ┌──────────┐ ┌──────────┐ │ │
│ │ │ USB │ │ Policy │ │ │
│ │ │ Bridge │ │ Cache │ │ │
│ │ └──────────┘ └──────────┘ │ │
│ │ │ │
│ └───────────────────────┬────────────────────────────────┘ │
│ │ │
│ ════════════════════════╪══════════════════ TB-4: SE Security Boundary ═ │
│ │ USB-C (Wired) │
│ │ │
│ ┌───────────────────────▼────────────────────────────────┐ │
│ │ Zone 3: HARDWARE SE ZONE │ │
│ │ Trust Level: ABSOLUTE │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ Signing │ │ WYSIWYS │ │ Policy │ │ │
│ │ │ Applet │ │ Applet │ │ Applet │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ ECDSA/ │ │ TX Parsing │ │ Amount Limit │ │ │
│ │ │ Schnorr Sign │ │ Hash Compare │ │ Whitelist MR │ │ │
│ │ │ Key Storage │ │ Display Ctrl │ │ Rate Limit │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────────────┐ │ │
│ │ │ Secure Storage: Private Keys, Policy Data, │ │ │
│ │ │ Merkle Root, Counters, Admin Public Keys │ │ │
│ │ └──────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ FORBIDDEN: Zone 1 ←→ Zone 3 Direct (AC-NW-01) │
│ FORBIDDEN: WiFi, Bluetooth (AC-NW-02). USB-C는 콜드월렛 전용 허용 │
│ │
└─────────────────────────────────────────────────────────────────────────┘
3.2. Trust Boundary 식별¶
| ID | Trust Boundary | 경계 위치 | 위협 수준 | 통신 채널 |
|---|---|---|---|---|
| TB-1 | 사용자 ↔ 대시보드 | 인터넷 / VPN | 높음 | HTTPS (TLS 1.3) |
| TB-2 | 대시보드 ↔ 블록체인 노드 | 네트워크 | 중간 | JSON-RPC / gRPC |
| TB-3 | 대시보드 ↔ 오프라인 앱 | 에어갭 | 낮음 | QR (UR) |
| TB-4 | 오프라인 앱 ↔ 콜드월렛 | SE 보안 경계 | 낮음 | USB-C |
| TB-5 | 대시보드 ↔ MPC 셰어 서버 | 내부 네트워크 | 중간 | mTLS |
4. Zone 간 통신 규칙¶
4.1. 허용 통신 매트릭스¶
| 방향 | 경로 | 채널 | 데이터 유형 | 최대 페이로드 |
|---|---|---|---|---|
| → | Zone 1 → Zone 2 | QR (UR Animated) | 미서명 TX, 정책 업데이트, 화이트리스트 | 제한 없음 (멀티프레임) |
| → | Zone 2 → Zone 3 | USB-C | SignRequest, PolicyUpdate | 제한 없음 |
| ← | Zone 3 → Zone 2 | USB-C | SignResponse, 에러 코드 | 제한 없음 |
| ← | Zone 2 → Zone 1 | QR (화면 표시) | 서명 결과, 위반 리포트 | ~2KB |
4.2. 금지 통신¶
| 규칙 | 근거 | 강제 수단 |
|---|---|---|
| Zone 1 ↔ Zone 3 직접 통신 금지 | AC-NW-01: 콜드월렛은 네트워크에 절대 연결 금지 | Zone 3 디바이스에 네트워크 스택 자체가 없음 |
| WiFi/Bluetooth 연결 금지. 오프라인 앱↔콜드월렛 간 USB-C 허용. | AC-NW-02: QR + USB-C만 허용 | Zone 2: MDM/비행기 모드. Zone 3: USB-C 외 네트워크 인터페이스 없음 |
| Zone 2의 네트워크 연결 금지 | 에어갭 원칙 | MDM 강제 + 물리적 NIC 비활성화 + 앱 네트워크 감지 시 경고 |
4.3. 통신 방향 원칙¶
TB-3(에어갭 경계)의 QR 통신은 단방향(Unidirectional)으로 설계된다. 각 데이터 전달은 독립적인 QR 세션이며, 양방향 핸드셰이크를 수행하지 않는다. TB-4(SE 보안 경계)의 USB-C 통신은 양방향(Bidirectional)이며, 오프라인 서명 앱과 콜드월렛이 하나의 오프라인 서명 유닛을 구성한다.
Request 흐름: Zone 1 ──QR──▶ Zone 2 ──USB-C──▶ Zone 3
Response 흐름: Zone 3 ──USB-C──▶ Zone 2 ──QR──▶ Zone 1
TB-3 구간에서 사용자가 물리적으로 카메라를 조작하여 QR을 스캔한다. 이 물리적 개입이 중간자 공격 방어의 핵심 메커니즘이다. TB-4 구간의 USB-C 연결은 SE 디바이스 인증을 통해 보안을 확보한다.
5. Zone별 컴포넌트 책임¶
5.1. Zone 1 (온라인 대시보드) 책임¶
| 책임 영역 | 상세 |
|---|---|
| 트랜잭션 생성 | PSBT (BIP-174/370) 생성, EIP-712 TypedData 구성, UTXO 선택, Gas 추정 |
| 1차 정책 검증 | 전체 정책 규칙 평가 (5종 + 확장), 에스컬레이션 판단 |
| 승인 관리 | M-of-N 승인 워크플로우 관리, 승인 상태 추적, 타임아웃 관리 |
| 서명 취합 | 부분 서명 수집, MuSig2 서명 집계, Safe execTransaction 구성 |
| 블록체인 전파 | TX 브로드캐스트, 멤풀 모니터링, 확인 대기, RBF/Gas 인상 |
| 감사 로그 관리 | SHA-256 해시 체이닝 로그, 5년+ 보존, 온/오프라인 로그 통합 |
| 사용자 인증 | MFA (TOTP + 하드웨어 키), RBAC 세션 관리, 접근 로깅 |
| Warm Tier 관리 | MPC-TSS 서명 세션 관리, 자동 리밸런싱, Kill Switch |
| QR 생성 | 서명 요청을 UR 인코딩 QR로 변환 |
5.2. Zone 2 (오프라인 서명 앱) 책임¶
| 책임 영역 | 상세 |
|---|---|
| 에어갭 브릿지 | Zone 1 → Zone 2 → Zone 3 데이터 중계 (양방향) |
| 2차 정책 검증 | 캐시된 정책 데이터로 핵심 규칙 재확인 (보조적 역할) |
| TX 내용 표시 | 사용자에게 TX 내용 표시 (수신 주소, 금액, 수수료) — 2차 시각 확인 |
| 서명 요청 중계 | SignRequest 메시지를 Zone 3에 전달 (USB-C) |
| 부분 서명 수집 | M-of-N 환경에서 여러 서명자의 부분 서명을 로컬에서 수집/병합 |
| 세션 관리 | 서명 세션 로컬 저장 (암호화), 타임아웃 관리 |
| APP_HASH 생성 | WYSIWYS 검증용 해시 생성 (Zone 3 SE_PARSE_HASH와 대조) |
5.3. Zone 3 (D'CENT X SE) 책임¶
| 책임 영역 | 상세 |
|---|---|
| WYSIWYS 파싱 | TX 원본 데이터 독립 파싱 (PSBT/RLP/ABI), 화면 표시 |
| WYSIWYS 검증 | SE_PARSE_HASH 생성 → APP_HASH 대조 → 불일치 시 서명 거부 |
| 3차 HW 정책 검증 | 건당 한도, Merkle Root 화이트리스트, 일일 누적, 서명 횟수 제한 |
| SE 내부 서명 | ECDSA secp256k1, Schnorr (BIP-340) 서명 수행 |
| 키 저장/관리 | TRNG 키 생성, SE 내부 암호화 저장, HD 키 파생 (BIP-44/84/86) |
| 정책 데이터 관리 | Admin 쿼럼 서명 검증 후 정책 업데이트, 쿨다운 관리 |
| 물리 버튼 승인 | 사용자의 명시적 물리 버튼 입력으로만 서명 실행 |
| 위반 보고 | 정책 위반 코드 반환 (0x01-0xFF), WYSIWYS 불일치 코드 반환 |
6. 신뢰 모델 (Trust Model)¶
6.1. Zero Trust 원칙¶
Zone 1 (대시보드) Zone 2 (오프라인 앱) Zone 3 (SE)
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Trust: LOW │ │ Trust: MEDIUM│ │ Trust: ABSOLUTE│
│ │ │ │ │ │
│ "Zone 2/3를 │ │ "Zone 1/3를 │ │ "외부 데이터를 │
│ 신뢰하지 │ │ 신뢰하지 │ │ 일체 신뢰하지 │
│ 않음" │ │ 않음" │ │ 않음" │
│ │ │ │ │ │
│ 서명 결과를 │ │ TX 데이터를 │ │ 수신 데이터를 │
│ 독립 검증 │ │ 독립 표시 │ │ 독립 파싱/검증 │
└──────────────┘ └──────────────┘ └──────────────┘
각 Zone의 검증 의무: - Zone 1: 서명 결과의 공개키 매칭, TX 무결성 해시 검증 - Zone 2: Zone 1에서 수신한 TX 데이터를 독립적으로 표시하여 사용자 확인 유도 - Zone 3: 수신 데이터를 SE 내부에서 독립 파싱하여 WYSIWYS 검증 수행
6.2. Root of Trust 계층¶
┌─────────────────┐
│ Zone 3: SE │ ◀── Root of Trust
│ (ABSOLUTE) │
│ 키 생성/저장/서명│
└────────┬────────┘
│ SE 서명으로 출력 검증
┌────────▼────────┐
│ Zone 2: App │ ◀── 중계 + 2차 검증
│ (MEDIUM) │
│ 에어갭 브릿지 │
└────────┬────────┘
│ 서명 결과 전달
┌────────▼────────┐
│ Zone 1: Dash │ ◀── 서명 취합 + 전파
│ (LOW) │
│ TX 생성/전파 │
└─────────────────┘
Root of Trust 원칙: 1. SE(Zone 3)가 생성한 서명만이 유효한 서명으로 인정 2. SE 외부의 어떤 소프트웨어도 서명을 생성하거나 변조할 수 없음 3. SE 내부 정책은 외부에서 실시간 우회 불가 (쿨다운 필수) 4. WYSIWYS 해시 비교가 Zone 2 → Zone 3 신뢰 검증의 핵심 메커니즘
6.3. 데이터 검증 매트릭스¶
| 데이터 | 생산 Zone | 소비 Zone | 검증 방식 |
|---|---|---|---|
| 미서명 TX (PSBT/EIP-712) | Zone 1 | Zone 3 | SE 독립 파싱 → WYSIWYS 표시 → APP_HASH/SE_PARSE_HASH 대조 |
| 서명 결과 | Zone 3 | Zone 1 | 공개키 매칭 + TX 해시 무결성 검증 |
| 정책 업데이트 | Zone 1 | Zone 3 | Admin 쿼럼 서명 검증 + 버전 번호 단조 증가 확인 |
| Merkle Proof | Zone 2 | Zone 3 | SE 내부 Merkle Root 대조 |
| 부분 서명 | Zone 3 | Zone 1 | Schnorr/ECDSA 서명 검증 (공개키 기반) |
7. 보안 계층 매핑 (AC-ID 제약조건)¶
7.1. Zone별 AC-ID 분포¶
| 카테고리 | Zone 1 (대시보드) | Zone 2 (오프라인 앱) | Zone 3 (SE) | 인터페이스 |
|---|---|---|---|---|
| AC-KM (키 관리) | 1 | 2 | 5 | 1 |
| AC-AC (접근 제어) | 5 | 1 | 1 | 0 |
| AC-AU (감사) | 3 | 1 | 1 | 1 |
| AC-TX (트랜잭션) | 3 | 1 | 2 | 1 |
| AC-NW (네트워크) | 3 | 2 | 2 | 3 |
| AC-DR (재해 복구) | 4 | 1 | 1 | 0 |
| AC-RP (리포팅) | 5 | 0 | 0 | 1 |
| AC-GV (거버넌스) | 7 | 1 | 2 | 1 |
| 합계 | 31 | 9 | 14 | 8 |
7.2. 에어갭 자동 충족 제약조건 (15개)¶
| ID | 설명 | 자동 충족 근거 |
|---|---|---|
| AC-NW-01 | 콜드월렛 네트워크 연결 금지 | Zone 3에 네트워크 스택 자체 없음 |
| AC-NW-02 | QR + USB-C만 허용 | Zone 1-2 간 QR, Zone 2-3 간 USB-C 물리적 채널만 존재 |
| AC-KM-01 | SE 내부 키 생성 (TRNG) | Zone 3 SE 내부에서만 수행 |
| AC-KM-02 | 키 SE 외부 추출 불가 | SE 하드웨어 설계상 물리적으로 불가 |
| AC-TX-02 | WYSIWYS + 물리 버튼 승인 | Zone 3 디바이스 화면 + 물리 버튼 |
| AC-NW-03 | 에어갭 데이터 무결성 | QR/USB-C 페이로드에 HMAC 포함 |
| AC-NW-04 | WiFi/Bluetooth 연결 금지. 오프라인 앱↔콜드월렛 간 USB-C 허용. | MDM/비행기 모드 + USB-C 디바이스 인증 |
| AC-KM-08 | 키 사용 로깅 | SE 내부 서명 카운터 |
| AC-TX-03 | 하드웨어 서명 확인 | SE 물리 버튼 필수 |
| AC-NW-05 | 통신 채널 제한 | QR/USB-C 외 인터페이스 없음 (Bluetooth 비활성화) |
| AC-KM-09 | SE 탬퍼 방지 | EAL5+ 물리적 보호 |
| AC-TX-04 | 다중 서명 필수 | MuSig2/Safe 구조상 단일 서명 불가 |
| AC-NW-06 | USB-C 디바이스 인증 | USB-C 연결 시 SE 기반 디바이스 인증 + 세션 키 교환 |
| AC-KM-10 | 키 파생 경로 격리 | BIP-44/84/86 경로 분리 |
| AC-GV-03 | 정책 변경 쿨다운 | SE 내부 쿨다운 타이머 강제 |
7.3. Zone 경계에서 추가 구현 필요 제약조건¶
| ID | 설명 | 구현 위치 | 구현 방향 |
|---|---|---|---|
| AC-AU-01 | 변조 불가 감사 로그 | Zone 1 + Zone 2 동기화 | SHA-256 해시 체이닝, 5년+ 보존 |
| AC-AU-02 | 온/오프라인 로그 동기화 | Zone 1 ↔ Zone 2 | QR 경유 로그 배치 동기화 |
| AC-AC-06 | 특권 접근 관리 | Zone 1 | Admin 세션 로깅, 시간 제한 |
| AC-GV-01 | 정책 버전 관리 | Zone 1 + Zone 3 | 단조 증가 버전, 롤백 방지 |
| AC-GV-02 | 정책 변경 쿼럼 승인 | Zone 1 → Zone 3 | Admin 서명 → 에어갭 → SE 검증 |
| AC-DR-01 | 키 백업/복구 절차 | Zone 3 | 금속 시드 백업, 키 세레모니 |
| AC-RP-01 | 규제 보고 기능 | Zone 1 | 감사 로그 기반 보고서 생성 |
| AC-DR-02 | 사업 연속성 계획 | Zone 1 + Zone 3 | 대체 서명자, 복구 드릴 |
8. 배포 모델별 Zone 구성¶
Phase 4 on-premise-zero-cloud.md에서 정의한 3가지 배포 모델에 대한 Zone 매핑:
8.1. 배포 모델별 Zone 1 구성¶
| 항목 | Model A (Zero Cloud) | Model B (Hybrid) | Model C (SaaS) |
|---|---|---|---|
| 대시보드 서버 | 기업 데이터센터 | 클라우드 (Private VPC) | D'CENT 호스팅 |
| 데이터베이스 | 온프레미스 PostgreSQL | 클라우드 DB | D'CENT 관리 DB |
| 블록체인 노드 | 셀프호스팅 | 하이브리드 (셀프 + 외부) | D'CENT 공유 노드 |
| 이벤트 스토어 | 온프레미스 | 클라우드 | D'CENT 관리 |
| MPC 셰어 서버 | 기업 서버 분산 | 기업 온프레미스 | 기업 서버 분산 |
8.2. 불변 Zone (모든 모델에서 동일)¶
| Zone | 소유 | 위치 | 변경 불가 원칙 |
|---|---|---|---|
| Zone 2 (오프라인 앱) | 항상 고객 소유 | 고객 시설 내 | 네트워크 차단 환경 |
| Zone 3 (콜드월렛 SE) | 항상 고객 소유 | 고객 물리적 보유 | 키는 항상 고객 SE 내부 |
핵심 보장: 어떤 배포 모델에서든 프라이빗 키와 서명 행위는 Zone 2/3에서만 수행되며, Zone 1의 배포 위치와 무관하게 에어갭 원칙이 유지된다.
8.3. 배포 모델별 보안 수준 비교¶
| 보안 항목 | Model A | Model B | Model C |
|---|---|---|---|
| 데이터 주권 | 완전 | 부분 (TX 메타데이터 클라우드) | 제한 (D'CENT 호스팅) |
| 키 보안 | 동일 (Zone 3 격리) | 동일 | 동일 |
| 서명 보안 | 동일 (에어갭) | 동일 | 동일 |
| 규제 대응 | 최고 (ISMS-P 자동 충족) | 높음 (추가 조치 필요) | 중간 (SLA 기반) |
| 운영 복잡도 | 높음 | 중간 | 낮음 |
9. 2-Tier 커스터디와의 Zone 매핑¶
Phase 4 tiered-custody-architecture.md의 2-Tier 커스터디를 Zone 아키텍처에 매핑한다.
9.1. Cold Tier 데이터 흐름¶
Cold Tier 트랜잭션은 3개 Zone을 모두 경유한다:
Zone 1 (TX 생성)
│
▼ QR (TB-3)
Zone 2 (에어갭 브릿지)
│
▼ USB-C (TB-4)
Zone 3 (SE 서명)
│
▼ USB-C (TB-4)
Zone 2 (서명 수집)
│
▼ QR (TB-3)
Zone 1 (서명 취합 + 전파)
보안 적용: 3중 정책 방어 (Zone 1 SW + Zone 2 Cache + Zone 3 HW) + WYSIWYS + 물리 버튼
9.2. Warm Tier 데이터 흐름¶
Warm Tier 트랜잭션은 Zone 1 내부에서 완결된다:
Zone 1 (TX 생성)
│
▼ 내부 네트워크 (TB-5)
Zone 1 (MPC-TSS 셰어 서버 → 분산 서명)
│
▼
Zone 1 (서명 취합 + 전파)
보안 적용: SW 정책만 (Zone 1 Policy Engine) + MPC-TSS t-of-n 임계 서명
9.3. Hot Tier 데이터 흐름 (선택적)¶
Hot Tier도 Zone 1 내부에서 완결:
Zone 1 (TX 자동 생성 → HSM/SW 키 서명 → 전파)
보안 적용: 최소 정책 (금액 상한) + 단일 키 또는 2-of-2
9.4. 계층별 Zone 경유 요약¶
| 커스터디 계층 | Zone 1 | Zone 2 | Zone 3 | 에어갭 횟수 |
|---|---|---|---|---|
| Cold Tier | 경유 | 경유 | 경유 | 4회 × M명 서명자 |
| Warm Tier | 내부 완결 | 미경유 | 미경유 | 0회 |
| Hot Tier | 내부 완결 | 미경유 | 미경유 | 0회 |
10. Phase 3/4 연계 사항¶
| Phase 3/4 설계 | 본 문서 반영 |
|---|---|
| airgap-signing-flow.md: 4단계 파이프라인 | Zone 경계를 기준으로 4단계 흐름을 재정의 |
| multisig-workflow.md: M-of-N 서명 수집 | Zone 2에서의 부분 서명 수집 및 Zone 1에서의 취합 |
| wysiwys-design.md: SE 파싱/해시 비교 | Zone 3 WYSIWYS Applet의 독립 파싱 및 해시 대조 |
| hardware-policy-engine.md: 4개 불변 규칙 | Zone 3 Policy Applet의 SE 내부 정책 검증 |
| tiered-custody-architecture.md: 2-Tier | Cold=전체 Zone 경유, Warm/Hot=Zone 1 내부 |
| on-premise-zero-cloud.md: 3가지 배포 모델 | Zone 1만 배포 위치 변동, Zone 2/3 불변 |
본 문서는 Phase 5 System Architecture Design의 기반 문서로, 에어갭 통신 프로토콜(airgap-communication-protocol.md), 컴포넌트 간 데이터 흐름(component-data-flow.md), STRIDE 위협 모델(stride-threat-model.md)의 아키텍처 참조점이 된다. Phase 2 컴플라이언스 매트릭스(compliance-architecture-matrix.md)의 42개 AC-ID 제약조건을 Zone 수준에서 매핑하였다.
관련 문서¶
- 에어갭 통신 프로토콜 설계서 -- 시스템 아키텍처
- 체인 추상화 레이어 인터페이스 정의서 -- 시스템 아키텍처
- 컴포넌트 간 데이터 흐름 및 인터페이스 명세 -- 시스템 아키텍처
- 온라인 대시보드 백엔드 아키텍처 설계서 -- 시스템 아키텍처
- D'CENT X 펌웨어 서명 인터페이스 설계서 -- 시스템 아키텍처
- 오프라인 서명 앱 아키텍처 설계서 -- 시스템 아키텍처
- STRIDE 기반 보안 위협 모델 -- 시스템 아키텍처