v0.3
SLIP-39 Shamir 백업 엔터프라이즈 설계서¶
1. Executive Summary¶
본 문서는 D'CENT 엔터프라이즈 콜드월렛 커스터디 솔루션에 SLIP-39(Shamir's Secret Sharing for Mnemonic Codes) 기반 시드 백업을 도입하기 위한 엔터프라이즈 적용 설계를 수립한다.
SLIP-39 도입 목적: 기존 BIP-39 니모닉 24단어 평문 백업은 단일 유출 시 전체 시드가 노출되는 근본적 한계가 있다. SLIP-39는 Shamir's Secret Sharing(SSS)을 적용하여 시드를 M-of-N 셰어로 분할함으로써, 개별 셰어 유출만으로는 시드 복원이 불가능하고, 최소 M개 셰어를 확보해야만 원본 시드를 재구성할 수 있다.
핵심 결론:
| 항목 | 내용 |
|---|---|
| 기본 Shamir (SSS-01) | SLIP-39 M-of-N 백업을 키 세레모니 Step 3에 통합하여 기존 금속 시드 백업을 분산형으로 대체/보완 |
| Super Shamir (SSS-02) | 다중 그룹 임계값 구조를 RBAC 역할(Super Admin/Admin/Approver)에 매핑하여 엔터프라이즈 거버넌스 반영 |
| SE 처리 요구사항 | SE 내부 GF(256) 분할이 이상적이나, HW-CONFIRM-R04 확인 전까지는 오프라인 앱 분할을 보수적 기본안으로 설계 |
| 하이브리드 전략 | Phase 16 결정(경로 C 의무화)에 따라 SLIP-39는 항상 R3covery 카드 또는 금속 시드와 병행 |
2. SLIP-39 기본 M-of-N 백업 설계 (SSS-01)¶
2.1. SLIP-39 프로토콜 개요¶
SLIP-39는 SatoshiLabs에서 제정한 Shamir's Secret Sharing 기반 니모닉 백업 표준이다.
핵심 기술 사양:
| 항목 | SLIP-39 | BIP-39 (비교) |
|---|---|---|
| 비밀 분할 방식 | GF(256) 기반 Shamir's Secret Sharing | 없음 (단일 니모닉) |
| 셰어 형식 | 20단어 또는 33단어 니모닉 (EMS 인코딩) | 12/24단어 니모닉 |
| 임계값 구조 | M-of-N (최소 M개 셰어로 복원) | N/A (1-of-1) |
| 그룹 지원 | Super Shamir: 다중 그룹, 그룹별 임계값 | N/A |
| Passphrase 지원 | 선택적 (SLIP-39 Passphrase) | 선택적 (BIP-39 Passphrase) |
| 체크섬 | RS1024 (Reed-Solomon) | SHA-256 기반 |
| 호환성 | Trezor Model T/Safe 5, 일부 호환 월렛 | 업계 표준 (대부분 호환) |
GF(256) Shamir's Secret Sharing 원리: - 유한체(Galois Field) GF(256) 위에서 차수 (M-1)인 다항식을 생성 - 원본 비밀(시드)은 다항식의 상수항(f(0)) - N개의 서로 다른 점(셰어)을 다항식 위에서 평가하여 생성 - 임의의 M개 셰어로 라그랑주 보간법을 적용하면 원본 다항식 복원 가능 - (M-1)개 이하의 셰어로는 원본에 대한 어떤 정보도 얻을 수 없음 (정보 이론적 보안)
2.2. 엔터프라이즈 M-of-N 구성 권장안¶
| 구성 | M | N | 적합 고객 | 복원 내결함성 | 공모 필요 인원 | 운영 복잡성 |
|---|---|---|---|---|---|---|
| 최소 | 2 | 3 | 소규모 기업 (3-5인), S4/S8 세그먼트 | 1장 분실 허용 | 2인 공모 필요 | Low |
| 표준 | 3 | 5 | 중규모 기관 (10-20인), S3/S6/S7 세그먼트 | 2장 분실 허용 | 3인 공모 필요 | Medium |
| 고보안 | 4 | 7 | 대규모 기관 (20인+), S1/S2/S5 세그먼트 | 3장 분실 허용 | 4인 공모 필요 | High |
M-of-N 결정 기준: - N >= 2M - 1 원칙: 최소 (M-1)장 분실을 허용하면서도 M장 확보 가능 - 공모 내성: M이 클수록 공모 공격에 강하지만 복구 절차가 복잡 - 운영 부담: 셰어 수가 증가하면 보관/검증/교체 비용 비례 증가
2.3. 키 세레모니 Step 3 통합 설계¶
기존 key-ceremony.md의 Step 3(시드 백업)을 SLIP-39 셰어 생성으로 확장한다.
기존 Step 3 (금속 시드 백업):
각 서명자별:
□ 디바이스 화면의 24단어 니모닉을 금속 시드 플레이트에 각인
□ 최소 2개 금속 플레이트 (Primary + Secondary)
□ 봉인 봉투에 봉인, 증인 서명
확장 Step 3 (SLIP-39 통합) — 옵션 선택형:
Step 3: 시드 백업 (서명자당 30-45분)
각 서명자별:
[Phase A: 백업 방식 결정]
□ 백업 방식 선택 (사전 정책에 의해 결정):
☐ 방식 1: 금속 시드 단독 (BIP-39 24단어) — 기존 방식
☐ 방식 2: SLIP-39 M-of-N 셰어 분할 — 분산 백업
☐ 방식 3: 하이브리드 (금속 시드 1매 + SLIP-39 셰어 N매)
→ Phase 16 결정에 따라 방식 3(하이브리드)이 기본 의무
[Phase B: SLIP-39 셰어 생성 (방식 2 또는 3 선택 시)]
□ SE 내부에서 시드로부터 SLIP-39 셰어 생성 [HW-CONFIRM-R06]
- M-of-N 파라미터 입력 (예: 3-of-5)
- SE가 GF(256) 다항식 생성 및 N개 셰어 평가
- 또는: 오프라인 앱에서 셰어 생성 (SE 미지원 시 — 섹션 5 참조)
□ 각 셰어(20단어)를 개별 매체에 기록:
☐ 금속 플레이트 각인 (셰어당 1매)
☐ R3covery 카드 SE 저장 (셰어당 1장)
☐ 또는 양쪽 모두 (최고 보안)
□ 기록 완료 후 셰어 검증:
- 각 셰어를 테스트 디바이스에서 읽기 테스트
- 체크섬(RS1024) 검증 통과 확인
□ 각 셰어 매체를 개별 봉인 봉투에 봉인
□ 봉투에 셰어 번호(1/N, 2/N, ...), 서명자 이름, 날짜 기록
□ 증인이 봉인 과정 확인 및 서명
[Phase C: 하이브리드 금속 시드 (방식 3 선택 시)]
□ 기존 Step 3 금속 시드 백업 절차 동시 수행 (BIP-39 24단어)
□ 금속 시드는 최후 폴백 수단으로 최고 보안 금고에 보관
[Phase D: 셰어 분산 보관]
□ N개 셰어를 최소 2개 이상 물리적 위치에 분산 보관
□ 동일 위치에 M개 이상 셰어가 집중되지 않도록 배치
□ 보관 위치별 셰어 번호 매핑 기록 (세레모니 기록에 포함)
Step 3 확장에 따른 소요 시간 변경:
| 백업 방식 | 기존 Step 3 | 확장 Step 3 | 증가분 |
|---|---|---|---|
| 금속 시드 단독 | 20분/서명자 | 20분/서명자 | 0분 (변경 없음) |
| SLIP-39 3-of-5 | N/A | 40분/서명자 | +20분 (셰어 5매 기록) |
| 하이브리드 (금속 + SLIP-39 3-of-5) | N/A | 45분/서명자 | +25분 |
2.4. SE 내부 처리 요구사항¶
이상적 시나리오: SE 내부 SLIP-39 처리
시드가 SE 외부로 평문 노출되지 않도록, SE 내부에서 GF(256) 분할을 수행하는 것이 보안적으로 최선이다.
SE 내부 처리 흐름:
시드(BIP-39) ──[SE 내부]──▶ GF(256) 다항식 생성
──▶ N개 셰어 평가
──▶ 각 셰어를 EMS 인코딩(20단어)
──▶ 디바이스 화면에 셰어 1개씩 순차 표시
──▶ 사용자가 각 셰어를 매체에 기록
──▶ 모든 셰어 표시 완료 후 SE 내부 셰어 삭제
SE 내부 처리 요구사항: - GF(256) 유한체 연산: 256개 원소의 곱셈/나눗셈 테이블 (~512 bytes) - 다항식 평가: O(M*N) GF(256) 연산 (경량) - EMS 워드리스트: 1024단어 x 평균 5바이트 = ~5KB ROM - 임시 메모리: 다항식 계수 M개 x 1바이트 = 최대 7바이트 (4-of-7)
[HW-CONFIRM-R06] D'CENT X SE의 JavaCard 환경에서 SLIP-39 GF(256) 셰어 생성이 구현 가능한지 확인 필요. SE의 가용 메모리(~5KB 워드리스트 + 연산 공간)와 JavaCard API 제약 조건 검토. Phase 16의 HW-CONFIRM-R04(EEPROM 관련)를 SLIP-39 SE 처리로 확장.
2.5. 셰어 물리적 저장 매체¶
| 매체 | 셰어 기록 방식 | 보안 수준 | 내구성 | 벤더 독립성 | 비용/셰어 |
|---|---|---|---|---|---|
| (a) 금속 플레이트 | 20단어 각인 (스탬프/각인기) | 중간 (평문 노출) | 최고 (내화, 내수, 무전원) | 최고 (표준 단어) | Low |
| (b) R3covery 카드 | SE 암호화 저장 (PIN 보호) | 높음 (암호화 + PIN) | 높음 (EEPROM 10-25년) | 낮음 (D'CENT 전용) | Medium |
| (c) 하이브리드 | 금속 + R3covery 카드 각 1개씩 | 최고 (이중 매체) | 최고 (상호 보완) | 중간 (금속이 탈출 경로) | High |
권장: 하이브리드(c)를 기본 정책으로 설정 — Phase 16 하이브리드 백업 의무화 결정과 일관.
2.6. 셰어 보관 절차¶
Phase 16의 봉인 봉투 패턴을 셰어 보관에 확장 적용한다.
셰어 보관 규칙:
| 규칙 | 내용 | 근거 |
|---|---|---|
| R-01: M 집중 금지 | 동일 물리 위치에 M개 이상 셰어 보관 금지 | 단일 사이트 침해로 시드 복원 방지 |
| R-02: 지리적 분산 | 최소 2개, 권장 3개 이상 물리적 위치에 분산 | DS-02(사이트 재해) 대비 |
| R-03: 봉인 보관 | 각 셰어는 개별 변조 방지 봉인 봉투에 봉인 | 비인가 접근 탐지 |
| R-04: 접근 통제 | 내화금고(UL-72 1시간 이상) + RBAC 기반 접근 | 물리 보안 + 논리 보안 병행 |
| R-05: 환경 통제 | 온도 0-35도C, 습도 30-70% (비응축) | EEPROM 보존 조건 (R3covery 카드 보관 시) |
5-of-5 셰어 분산 예시 (3-of-5 구성):
| 셰어 | 보관 위치 | 금고 유형 | 접근 권한 (RBAC) |
|---|---|---|---|
| 셰어 1 | 본사 금고 A | 내화금고 (UL-72 Class 350) | Super Admin + Admin |
| 셰어 2 | 본사 금고 B (별도 층/건물) | 내화금고 | Admin + Approver |
| 셰어 3 | 원격 사이트 1 (은행 안전금고) | 은행 금고 | Super Admin + 은행 담당 |
| 셰어 4 | 원격 사이트 2 (법률 사무소 금고) | 법률 에스크로 | Admin + 법률 대리인 |
| 셰어 5 | 비상 보관소 (경영진 자택 금고) | 가정용 금고 | Super Admin 전용 |
3. Super Shamir 엔터프라이즈 거버넌스 매핑 (SSS-02)¶
3.1. Super Shamir(SLIP-39 Advanced) 개요¶
Super Shamir는 SLIP-39의 고급 기능으로, 2단계 임계값 구조를 지원한다.
2단계 구조:
Level 1: 그룹 임계값
그룹 A (Super Admin): 2-of-3 셰어
그룹 B (Admin): 3-of-5 셰어
그룹 C (비상금고): 1-of-1 셰어
Level 2: 전체 그룹 임계값
전체: 2-of-3 그룹 필요
→ 그룹 A + B가 모두 임계값 충족해야 복원
→ 또는 그룹 A + C, 또는 그룹 B + C
기본 Shamir 대비 Super Shamir 장점:
| 측면 | 기본 Shamir | Super Shamir |
|---|---|---|
| 역할 반영 | 모든 셰어 동등 가중치 | 역할별 그룹으로 차등 가중치 |
| 공모 방어 | 단일 그룹 내 M인 공모 | 다중 그룹 간 공모 필요 (난이도 상승) |
| 거버넌스 | 평면적 | 조직 계층 구조 반영 가능 |
| 복구 유연성 | 단일 임계값 | 그룹별 임계값 + 전체 임계값 2단계 |
| 운영 복잡성 | 중간 | 높음 (그룹 관리, 교차 검증) |
3.2. RBAC 역할 매핑¶
rbac-role-model.md에 정의된 5개 역할(Super Admin, Admin, Initiator, Approver, Viewer) 중 키 관리와 직접 관련된 3개 역할을 Super Shamir 그룹으로 매핑한다.
역할-그룹 매핑 원칙:
| RBAC 역할 | Super Shamir 그룹 | 매핑 근거 |
|---|---|---|
| Super Admin | 그룹 A (경영진) | 시스템 최고 권한자, 긴급 복구 주관, 1-2인 소수 |
| Admin | 그룹 B (운영팀) | 정책 관리자, 키 세레모니 리더, 2-5인 중간 규모 |
| Approver | 그룹 C (서명자) | 실제 서명 수행자, 콜드월렛 보유자, 3-7인 다수 |
Initiator/Viewer 제외 근거: - Initiator: 트랜잭션 생성만 수행, 키/시드 접근 불필요 - Viewer: 읽기 전용, 키/시드 접근 불필요
3.3. Super Shamir 구성안¶
구성안 1: 표준 3그룹 구조 (권장 — 중규모 이상)
그룹 A (Super Admin): 2-of-3 → 경영진 3인 중 2인
그룹 B (Admin): 2-of-3 → 운영팀 3인 중 2인
그룹 C (Approver): 3-of-5 → 서명자 5인 중 3인
전체 그룹 임계값: 2-of-3 그룹
→ 복원 시 임의 2개 그룹의 임계값 충족 필요
| 시나리오 | 그룹 A 충족 | 그룹 B 충족 | 그룹 C 충족 | 복원 가능 |
|---|---|---|---|---|
| 정상 복구 | 2/3 확보 | 2/3 확보 | - | 가능 |
| 경영진 비가용 | 불가 | 2/3 확보 | 3/5 확보 | 가능 |
| 운영팀 비가용 | 2/3 확보 | 불가 | 3/5 확보 | 가능 |
| 서명자 비가용 | 2/3 확보 | 2/3 확보 | 불가 | 가능 |
| 경영진+운영팀 비가용 | 불가 | 불가 | 3/5 확보 | 불가 |
구성안 2: 2그룹 구조 (소규모 기업)
그룹 A (경영진+운영팀): 2-of-3 → Super Admin 1 + Admin 2 혼합
그룹 B (서명자): 2-of-3 → Approver 3인 중 2인
전체 그룹 임계값: 2-of-2 그룹
→ 두 그룹 모두 임계값 충족 필요
구성안 3: 4그룹 구조 (대규모 기관/수탁사)
그룹 A (경영진): 1-of-2 → Super Admin 2인 중 1인
그룹 B (운영팀): 2-of-3 → Admin 3인 중 2인
그룹 C (서명자): 3-of-5 → Approver 5인 중 3인
그룹 D (비상금고): 1-of-1 → 물리적 에스크로 (법률 사무소/은행)
전체 그룹 임계값: 2-of-4 그룹
→ 비상금고 단독으로는 불가, 반드시 인적 그룹 1개 이상 필요
3.4. 역할별 셰어 분배 시나리오¶
시나리오 A: 소규모 기업 (3-5인)
| 인원 | 역할 | 그룹 | 셰어 수 | 보관 |
|---|---|---|---|---|
| CEO | Super Admin | 그룹 A | 1 | 자택 금고 |
| CTO | Admin | 그룹 A | 1 | 본사 금고 |
| 재무담당 | Admin | 그룹 A | 1 | 원격 사이트 |
| 서명자 1 | Approver | 그룹 B | 1 | 본사 금고 |
| 서명자 2 | Approver | 그룹 B | 1 | 원격 사이트 |
| 서명자 3 | Approver | 그룹 B | 1 | 은행 안전금고 |
구성: 그룹 A 2-of-3 + 그룹 B 2-of-3, 전체 2-of-2
시나리오 B: 중규모 기관 (10-20인)
| 인원 | 역할 | 그룹 | 셰어 수 | 보관 |
|---|---|---|---|---|
| CEO | Super Admin | 그룹 A | 1 | 별도 사이트 |
| COO | Super Admin | 그룹 A | 1 | 별도 사이트 |
| CFO | Super Admin | 그룹 A | 1 | 별도 사이트 |
| CISO | Admin | 그룹 B | 1 | 본사 금고 A |
| 운영관리자 1 | Admin | 그룹 B | 1 | 본사 금고 B |
| 운영관리자 2 | Admin | 그룹 B | 1 | 원격 사이트 |
| 서명자 1-5 | Approver | 그룹 C | 각 1 | 5개 분산 위치 |
구성: 그룹 A 2-of-3 + 그룹 B 2-of-3 + 그룹 C 3-of-5, 전체 2-of-3
시나리오 C: 대규모 기관/수탁사 (20인+)
| 인원 | 역할 | 그룹 | 셰어 수 | 보관 |
|---|---|---|---|---|
| CEO/CTO | Super Admin | 그룹 A | 각 1 | 개인 고보안 금고 |
| CISO + 운영진 3인 | Admin | 그룹 B | 각 1 | 본사 + 원격 3개 사이트 |
| 서명자 5-7인 | Approver | 그룹 C | 각 1 | 5-7개 분산 위치 |
| 법률 에스크로 | 비상금고 | 그룹 D | 1 | 법률 사무소 금고 |
구성: 그룹 A 1-of-2 + 그룹 B 2-of-3 + 그룹 C 3-of-5 + 그룹 D 1-of-1, 전체 2-of-4
3.5. 공모 공격 분석¶
단일 그룹 내 공모:
| 그룹 | 임계값 | 공모 필요 인원 | 공모만으로 복원 가능? | 분석 |
|---|---|---|---|---|
| A (경영진) | 2-of-3 | 2인 | 불가 (전체 임계값 미충족) | 경영진 2인이 공모해도 다른 그룹 셰어 필요 |
| B (운영팀) | 2-of-3 | 2인 | 불가 | 운영팀 2인이 공모해도 다른 그룹 셰어 필요 |
| C (서명자) | 3-of-5 | 3인 | 불가 | 서명자 3인이 공모해도 다른 그룹 셰어 필요 |
그룹 간 공모:
| 공모 조합 | 필요 인원 | 난이도 | 평가 |
|---|---|---|---|
| A(2인) + B(2인) | 4인 | 높음 | 경영진+운영팀 간 부서 경계 공모 |
| A(2인) + C(3인) | 5인 | 매우 높음 | 경영진+서명자 간 계층 경계 공모 |
| B(2인) + C(3인) | 5인 | 매우 높음 | 운영팀+서명자 간 계층 경계 공모 |
안전 마진: Super Shamir 구성안 1(표준)에서 시드 탈취를 위해 최소 4인의 그룹 간 공모가 필요하며, 이는 기본 Shamir 3-of-5의 3인 공모 대비 33% 향상된 공모 내성을 제공한다. 또한 공모자가 서로 다른 조직 계층에 속해야 하므로 실질적 공모 난이도는 수치 이상으로 높다.
3.6. Super Shamir vs 기본 Shamir 트레이드오프¶
| 평가 축 | 기본 Shamir | Super Shamir | 권장 |
|---|---|---|---|
| 보안 강도 | M인 공모로 복원 | 그룹 간 공모 필요 (더 강력) | Super Shamir |
| 거버넌스 정합성 | 역할 무관 동등 셰어 | RBAC 역할 반영 | Super Shamir |
| 운영 복잡성 | 단순 (셰어 N개 관리) | 복잡 (그룹 + 셰어 관리) | 기본 Shamir |
| 복구 소요 시간 | 30-60분 | 60-120분 (그룹별 수집) | 기본 Shamir |
| 교육 부담 | 낮음 (셰어 개념만) | 중간 (그룹 + 임계값 이해) | 기본 Shamir |
| 최소 인원 | 3인 (2-of-3) | 6인 (2그룹 x 3인) | 기본 Shamir |
| CCSS 매핑 | Level II 충족 | Level III 가능 | Super Shamir |
권장 전략: - 소규모 기업 (S4/S8): 기본 Shamir 2-of-3 또는 3-of-5 - 중규모 기관 (S3/S6/S7): 기본 Shamir 3-of-5 또는 Super Shamir 2그룹 - 대규모 기관 (S1/S2/S5): Super Shamir 3-4그룹
4. 복구 절차¶
4.1. SLIP-39 기본 복구 플로우¶
Step 1: 복구 의사결정 (10분)
□ 복구 필요 사유 확인 (DS-01~DS-06 매핑)
□ 복구 승인: Admin 쿼럼 (2-of-3) 승인
□ 필요 셰어 수(M) 확인
Step 2: 셰어 수집 (30-120분, 지리적 분산 정도에 따라)
□ M개 이상 셰어 보관 위치에서 셰어 회수
□ 각 셰어의 봉인 상태 확인 (변조 여부)
□ 봉인 개봉 시 증인 입회 + 사진 기록
□ 셰어 이동 시 보안 운송 (2인 동행)
Step 3: 시드 재조립 (15분)
□ 오프라인 환경(콜드룸 또는 격리 공간) 확보
□ 네트워크 차단 확인
□ D'CENT X 신규/리셋 디바이스 준비
□ M개 셰어를 디바이스에 입력 (SE 내부에서 재조립)
- 또는: 오프라인 앱에서 셰어 입력 → SE로 시드 전송
□ 시드 재조립 완료 → 파생 주소 확인 (기존 주소와 일치)
Step 4: 검증 및 마무리 (15분)
□ 복원된 디바이스의 주소가 기존 월렛 주소와 일치하는지 확인
□ 테스트 서명 수행 (소액 테스트 TX)
□ 사용한 셰어를 새 봉인 봉투에 재봉인
□ 복구 감사 로그 기록
□ 복구 완료 보고 (참석자 서명)
4.2. Super Shamir 복구 플로우¶
Step 1: 복구 의사결정 (동일)
Step 2: 그룹별 셰어 수집 (60-180분)
□ 어느 그룹 조합으로 복구할지 결정
- 예: 그룹 A(경영진) + 그룹 B(운영팀) 선택
□ 그룹 A의 임계값 충족 셰어 수집 (2-of-3 → 2개 확보)
□ 그룹 B의 임계값 충족 셰어 수집 (2-of-3 → 2개 확보)
□ 봉인 확인 및 개봉 (각 그룹별로 별도 수행)
Step 3: 2단계 시드 재조립 (20분)
□ 오프라인 환경 확보
□ 그룹 A 셰어 입력 → 그룹 A 비밀 조각 복원
□ 그룹 B 셰어 입력 → 그룹 B 비밀 조각 복원
□ 그룹 비밀 조각 결합 → 원본 시드 재조립
□ 파생 주소 확인
Step 4: 검증 및 마무리 (동일)
4.3. 재해 복구 시나리오 매핑¶
disaster-recovery.md의 DS-01~DS-06과 SLIP-39 복구를 매핑한다.
| 재해 시나리오 | 영향 | SLIP-39 복구 경로 | RTO 영향 |
|---|---|---|---|
| DS-01: 단일 디바이스 장애 | 1인 서명 불가 | SLIP-39 셰어로 시드 복원 → 신규 디바이스에 키 복구 | RTO 4-8h 유지 |
| DS-02: 사이트 재해 | 해당 사이트 셰어 접근 불가 | 분산 보관 셰어에서 M개 확보 (R-01 규칙에 의해 사이트당 < M개) | RTO 24-48h |
| DS-03: 서명자 비가용 | 해당 서명자 셰어 접근 제한 | 봉인 에스크로에서 해당 셰어 회수 → 복원 | RTO 4-8h |
| DS-04: 소프트웨어 장애 | 대시보드 불가 | SLIP-39에 직접 영향 없음 (오프라인 백업) | N/A |
| DS-05: 보안 침해 | 시드 노출 의심 | 긴급 자산 이전 → 새 시드 생성 → 새 SLIP-39 셰어 배포 | RTO 1-2h (긴급) |
5. SE 처리 분석 및 HW-CONFIRM¶
5.1. SE 내부 SLIP-39 처리 실현 가능성¶
JavaCard 환경에서 GF(256) 연산 구현 분석:
| 요구사항 | JavaCard 지원 | 실현 가능성 | 비고 |
|---|---|---|---|
| GF(256) 곱셈/나눗셈 | 바이트 배열 연산으로 구현 가능 | 가능 | 룩업 테이블 512바이트 |
| 다항식 평가 | 반복 연산 (Horner's method) | 가능 | M*N 바이트 연산 |
| EMS 워드리스트 | ROM/EEPROM에 저장 (~5KB) | 조건부 | SE 가용 메모리에 의존 |
| 랜덤 다항식 계수 | JavaCard TRNG API | 가능 | RandomData.generateData() |
| RS1024 체크섬 | 바이트 배열 연산 | 가능 | GF(1024) 연산 필요 |
결론: GF(256) 연산 자체는 JavaCard에서 구현 가능하나, EMS 워드리스트(~5KB)의 SE 메모리 상주 여부가 핵심 제약이다.
5.2. 대안: 오프라인 앱 셰어 생성¶
SE 내부 SLIP-39 처리가 불가능한 경우의 대안 경로이다.
대안 흐름:
SE에서 BIP-39 니모닉 24단어 → 디바이스 화면 표시
↓
사용자가 오프라인 앱에 24단어 입력 (에어갭 환경)
↓
오프라인 앱에서 SLIP-39 셰어 생성 (GF(256) 분할)
↓
각 셰어(20단어)를 개별 매체에 기록
↓
오프라인 앱 메모리 보안 삭제
보안 트레이드오프:
| 항목 | SE 내부 처리 | 오프라인 앱 처리 |
|---|---|---|
| 시드 평문 노출 | SE 외부 노출 없음 | 오프라인 앱 메모리에 일시 노출 |
| 노출 시간 | 0초 | 수 분 (셰어 생성 + 기록 시간) |
| 공격 표면 | SE 하드웨어 보안 | 앱 메모리 덤프, 화면 캡처 |
| 완화 방안 | N/A | 에어갭 격리, 메모리 즉시 삭제, 콜드룸 환경 |
위험 평가: 오프라인 앱 처리 시 시드가 앱 메모리에 수 분간 존재하나, (1) 에어갭 격리 환경, (2) 콜드룸 물리 보안, (3) 즉시 메모리 삭제에 의해 잔여 위험은 LOW 수준으로 평가. 다만 CCSS Level 3을 목표하는 고객에게는 SE 내부 처리를 권장.
5.3. HW-CONFIRM-R06 상세화¶
Phase 16에서 식별한 HW-CONFIRM-R04(EEPROM 관련)를 SLIP-39 SE 처리로 확장하여 신규 항목을 정의한다.
| 항목 ID | 질문 | 설계 영향도 | 대안 (확인 전 기본값) |
|---|---|---|---|
| HW-CONFIRM-R06 | D'CENT X SE에서 SLIP-39 GF(256) 셰어 생성이 구현 가능한가? (JavaCard 메모리 제약, EMS 워드리스트 탑재 가능성) | High | 불가 가정 → 오프라인 앱 처리를 기본안으로 설계 |
| HW-CONFIRM-R07 | SE에서 SLIP-39 셰어를 생성할 경우, 셰어를 화면에 순차 표시하는 UX 플로우가 펌웨어에서 지원 가능한가? | Medium | 가능 가정 → BIP-39 니모닉 표시와 동일 UX 패턴 |
| HW-CONFIRM-R08 | SE에서 SLIP-39 셰어를 입력받아 시드를 재조립(복원)하는 역방향 연산이 가능한가? | High | 불가 가정 → 오프라인 앱에서 재조립 후 SE에 시드 전송 |
6. 보안 분석¶
6.1. STRIDE 관점 위협 분석¶
| STRIDE 위협 | 셰어 생성 단계 | 셰어 보관 단계 | 셰어 복원 단계 |
|---|---|---|---|
| Spoofing | 가짜 셰어 생성 도구 | 가짜 셰어로 교체 | 가짜 셰어 입력 |
| Tampering | 셰어 내용 변조 | 봉인 훼손 후 셰어 교체 | 복원 과정 중 셰어 변조 |
| Repudiation | 셰어 생성 부인 | 셰어 접근 부인 | 복원 참여 부인 |
| Info Disclosure | 셰어 생성 중 도청 | 보관 위치 유출, 봉인 개봉 | 복원 중 평문 노출 |
| DoS | 셰어 생성 방해 | 셰어 파괴/분실 | 복원 방해 |
| Elevation | N/A | 비인가 셰어 접근 | 권한 없는 복원 시도 |
주요 완화 조치:
| 위협 | 완화 조치 | 잔여 위험 |
|---|---|---|
| 셰어 도청 | 콜드룸 환경, 에어갭 격리 | LOW |
| 셰어 물리 탈취 | M 집중 금지 규칙(R-01), 봉인 봉투, 내화금고 | LOW |
| 셰어 변조 | RS1024 체크섬, 봉인 무결성 검증 | LOW |
| M개 셰어 공모 | Super Shamir 그룹 간 분리, RBAC 계층 | MEDIUM (내부자 위협 잔존) |
| 전체 셰어 파괴 | 지리적 분산(R-02), 하이브리드 백업(금속 시드 폴백) | LOW |
6.2. Phase 16 PIN 관리와의 연동¶
SLIP-39 Passphrase는 Phase 16 pin-management-system-design.md에서 PIN-03으로 분류된 세 번째 PIN 유형이다.
Phase 16 결정 사항 준수: - SLIP-39 Passphrase는 Shamir 분할하지 않음 (Phase 16 결정: "SLIP-39 자체가 M-of-N이므로 이중 분할은 복잡성만 증가") - Passphrase 관리: 봉인 봉투 에스크로로 물리적 보관 (Shamir 분할 불필요) - Passphrase 분실 시: SLIP-39 셰어만으로는 복원 불가 → R3covery 카드 또는 금속 시드 폴백 필요 → 하이브리드 백업 의무화의 또 다른 근거
PIN-Passphrase-셰어 관계 정리:
시드 보호 체계 (다층 방어):
Layer 1: 물리적 보안 (금고, 봉인, 접근 통제)
Layer 2: SLIP-39 M-of-N 분할 (단일 셰어 무가치)
Layer 3: SLIP-39 Passphrase (셰어 조합에 추가 인증)
Layer 4: R3covery 카드 PIN (카드 SE 접근 인증)
Layer 5: 디바이스 PIN (본체 SE 접근 인증)
→ 최대 5단계 방어 계층 (하이브리드 + Super Shamir + Passphrase 사용 시)
본 문서는 Phase 17 백업 옵션 카탈로그 및 운영 설계의 일부로, r3covery-card-lifecycle-operations.md와 함께 Phase 17-02 백업 옵션 통합 카탈로그의 입력으로 사용된다. Phase 16의 r3covery-card-technical-analysis.md(HW-CONFIRM 항목)와 pin-management-system-design.md(PIN 라이프사이클)의 결정 사항을 준수한다.
관련 문서¶
- 백업 옵션 통합 카탈로그 및 고객별 권장 조합 가이드 -- 제품 설계
- R3covery 카드 라이프사이클 운영 절차서 -- 제품 설계