v0.5

2단계 서명 아키텍처 옵션 비교 평가 및 최적안 선정¶

1. 현재 아키텍처 문제 요약¶

현재 D'CENT 엔터프라이즈 콜드월렛 시스템은 3-Zone 보안 아키텍처(Online/Offline/Hardware SE)와 5개 Trust Boundary(TB-1~TB-5)를 기반으로 설계되어 있다. 그러나 다음 세 가지 구조적 한계가 존재한다.

Approver/서명자 역할 미분리: Approver가 곧 서명자이므로, 승인과 서명이 동일한 물리적 공간(콜드룸)에서 동일인에 의해 수행된다. 이는 CCSS Level 2+ 듀얼 컨트롤 요구사항에 부합하지 않는다.
콜드룸 전원 집결 필요: M-of-N 다중 서명을 위해 최소 M명의 서명자가 콜드룸에 물리적으로 집결해야 하며, 이는 일상 출금의 운영 비용과 소요 시간을 크게 증가시킨다.
MuSig2 QR 24회 한계: BTC 3-of-5 MuSig2 서명 시 3명 x 2라운드 x 4회 QR = 최소 24회 QR 스캔이 필요하며, 이는 실사용 한계에 도달했다.

이 문제들을 해결하기 위해 개인 서명 기기(Personal Signing Device, PSD)를 도입하여 오프체인 승인과 온체인 서명을 분리하는 2단계 서명 아키텍처를 설계한다.

2. 옵션 A: 오프체인 승인 + 온체인 마스터 서명 완전 분리¶

2.1. 구조 개요¶

개인 기기는 오프체인 승인 전용 키만 보유하고, 블록체인 서명 키는 콜드월렛 SE에만 보관한다. 두 키가 수학적으로 완전히 독립되어 개인 기기 키 유출이 온체인 자산에 직접 영향을 주지 않는다.

Stage 1: 개인 기기 승인 (오프체인)

  Approver 1 ──[개인 기기 SE]──> approval_sig_1 (ECDSA secp256k1)
  Approver 2 ──[개인 기기 SE]──> approval_sig_2
  Approver M ──[개인 기기 SE]──> approval_sig_M
          |
          v  (오프라인 앱이 M개 승인 서명 수집)

Stage 2: 콜드월렛 최종 서명 (온체인)

  ┌─────────────────────────────────────────────────┐
  │ 콜드월렛 SE (Zone 3)                              │
  │                                                    │
  │  1. M개 approval_sig 검증 (등록된 공개키로)        │
  │  2. M-of-N 임계값 충족 확인                        │
  │  3. WYSIWYS 파싱 + 물리 버튼 확인                  │
  │  4. HW 정책 검증 (4개 불변 규칙)                   │
  │  5. 마스터 키로 블록체인 서명                       │
  │     BTC: Schnorr (BIP-340)                        │
  │     EVM: ECDSA secp256k1                          │
  └─────────────────────────────────────────────────┘

  온체인 표현: 단일 서명 (마스터 키)

2.2. 키 구조¶

키 유형	알고리즘	보관 위치	역할	블록체인 노출
개인 기기 키 (approval_sk)	ECDSA secp256k1	개인 기기 SE	오프체인 승인 전용	없음
콜드월렛 마스터 키 (master_sk)	BIP-340 Schnorr (BTC) / ECDSA (EVM)	콜드월렛 SE	온체인 블록체인 서명	있음

2.3. 키 관계¶

수학적 관계: 두 키는 독립적 엔트로피에서 생성되며 공유 시드가 없다. approval_sk의 개인 키 값으로부터 master_sk를 유도하는 것은 계산적으로 불가능하다 (이산 로그 문제).
프로토콜적 관계: approval_sk 서명 M개가 콜드월렛 SE의 Approval Verifier를 통과해야 master_sk 서명이 실행된다. 이는 SE 펌웨어 레벨의 전제 조건이다.

2.4. 서명 흐름¶

Request: 대시보드에서 미서명 TX 생성 (PSBT 또는 EIP-712)
Approve: M-of-N 개인 기기에서 TX 해시에 ECDSA 승인 서명 (비동기, stateless)
Collect: 오프라인 앱이 승인 서명 M개 수집하여 ApprovalBundle 생성
Sign: 콜드월렛 SE가 ApprovalBundle 검증 후 마스터 키로 블록체인 서명
Broadcast: 서명된 TX를 대시보드가 블록체인 네트워크에 전파

2.5. 장점¶

키 독립성: 개인 기기 키 유출이 온체인 자산에 직접 영향 없음
MuSig2 QR 오버헤드 근본 해소: 콜드월렛이 단일 마스터 키로 서명하므로 MuSig2 2라운드 프로토콜 불필요
비동기 승인: 승인 서명은 stateless이므로 시간/장소에 구애받지 않고 수집 가능
키 교체 용이: 개인 기기 키 교체 시 블록체인 주소 변경 불필요 (revocable)
온체인 효율: 단일 서명만 온체인에 기록되어 수수료 최소, 프라이버시 최대

2.6. 단점¶

콜드월렛 마스터 키 SPOF: 마스터 키가 단일 장애점이 되며, SE의 물리적 탈취 + Approval Verifier 우회 시 자산 탈취 가능
Approval Verifier SE 구현 필요: 콜드월렛 SE 펌웨어에 승인 서명 검증 로직을 새로 추가해야 함
SE 비휘발성 메모리 사용: 개인 기기 공개키 레지스트리를 SE 내부에 저장해야 하며, 저장 용량 제약 확인 필요

3. 옵션 B: 온체인 키 분산 (개인 기기에 MuSig2/FROST 키 셰어)¶

3.1. 구조 개요¶

개인 기기가 MuSig2 partial key 또는 FROST key share를 직접 보유하여 온체인 서명에 직접 참여한다. 콜드월렛은 키 셰어 중 하나를 보유하거나 서명 집계자 역할만 수행한다.

키 분산: 개인 기기가 서명 키 직접 보유

  개인 기기 1 SE: signer_key_1 (MuSig2 참여자 키)
  개인 기기 2 SE: signer_key_2
  개인 기기 N SE: signer_key_N
  콜드월렛 SE: aggregator_key (서명 취합/집계)

  서명 플로우:
  1. 각 개인 기기에서 MuSig2 Round 1 (nonce 생성)
  2. 오프라인 앱이 nonce 수집/배포
  3. 각 개인 기기에서 MuSig2 Round 2 (부분 서명)
  4. 오프라인 앱이 부분 서명 수집
  5. 콜드월렛에서 집계 서명 생성

  온체인 표현: 단일 집계 Schnorr 서명 (BTC) / M개 서명 (EVM Safe)

3.2. 키 구조¶

키 유형	알고리즘	보관 위치	역할	블록체인 노출
개인 기기 키 (signer_key_i)	BIP-327 MuSig2 partial key	개인 기기 SE	온체인 부분 서명	간접 (집계 후 노출)
콜드월렛 키 (aggregator_key)	BIP-327 MuSig2 partial key	콜드월렛 SE	온체인 부분 서명 + 집계	간접

3.3. 키 관계¶

수학적 관계: 모든 키가 동일한 MuSig2 키 집계 과정에 참여한다. N개의 partial key가 수학적으로 결합되어 단일 aggregated public key를 생성한다 (P_agg = H(L, P_1)*P_1 + ... + H(L, P_N)*P_N).
프로토콜적 관계: M-of-N 임계값을 위해서는 FROST가 필요하다. BIP-327 MuSig2는 N-of-N만 지원하므로 M-of-N 구현 시 Taproot Script Tree에 C(N,M) 조합을 배치해야 한다.

3.4. 장점¶

진정한 다중 서명: 단일 장애점이 없으며, 어떤 단일 기기도 독자적으로 서명 불가
키 분산: 키 셰어가 물리적으로 분산되어 단일 지점 탈취로 자산 탈취 불가
임계값 안전성: M개 미만의 키 유출로는 서명 생성 불가

3.5. 단점¶

개인 기기 2대 탈취 = 자산 탈취 가능 (Pitfall 3): 2-of-3 구성에서 개인 기기 2대가 탈취되면 콜드월렛 없이도 온체인 서명 가능. 이는 콜드월렛 중심 보안 모델을 근본적으로 훼손한다.
MuSig2 QR 오버헤드 해소 불가: 개인 기기 간 2라운드 nonce 교환이 필요하며, 에어갭 비동기 환경에서 이는 극도로 비실용적이다.
키 교체 시 블록체인 주소 변경: 개인 기기 키 교체 시 aggregated key가 변경되므로 블록체인 주소가 바뀌고 키 세레모니 재실행이 필요하다.
FROST 미성숙: BIP-445는 Draft v0.4.1 상태이며 SE 구현 사례가 없다. MuSig2 N-of-N만으로는 M-of-N 지원이 불가하여 Taproot Script Tree 조합 폭발 문제가 발생한다 (5-of-7 = C(7,5) = 21개 리프).
nonce 상태 관리 복잡도 (Pitfall 1): 개인 기기 SE에서 MuSig2 nonce 상태를 관리해야 하며, 전원 꺼짐 시 세션 손실 위험이 있다.

4. 옵션 C: 하이브리드 (오프체인 승인 + 콜드월렛 MuSig2 필수 참여)¶

4.1. 구조 개요¶

개인 기기는 오프체인 승인(옵션 A와 동일)을 수행하면서 동시에 Taproot Script Path의 리프 키로 온체인 부분 서명에도 참여한다. 콜드월렛은 승인 검증과 함께 나머지 MuSig2 리프 서명 및 집계를 수행한다.

Stage 1: 개인 기기 승인 + 부분 서명

  Approver 1 ──[개인 기기 SE]──> approval_sig_1 (오프체인)
                               + partial_sig_1 (온체인 Taproot leaf)
  Approver M ──[개인 기기 SE]──> approval_sig_M + partial_sig_M

Stage 2: 콜드월렛 검증 + 집계

  ┌─────────────────────────────────────────────────┐
  │ 콜드월렛 SE (Zone 3)                              │
  │  1. 승인 서명 검증 (옵션 A 동일)                   │
  │  2. 부분 서명 검증 + 나머지 MuSig2 서명            │
  │  3. 집계 서명 생성                                 │
  └─────────────────────────────────────────────────┘

  온체인 표현: 단일 Schnorr (key path) 또는 script path 서명

4.2. 키 구조¶

키 유형	알고리즘	보관 위치	역할	블록체인 노출
개인 기기 승인 키 (approval_sk)	ECDSA secp256k1	개인 기기 SE	오프체인 승인	없음
개인 기기 서명 키 (leaf_sk_i)	BIP-340 Schnorr	개인 기기 SE	Taproot leaf 부분 서명	간접
콜드월렛 키 (master_sk + leaf_sk_cw)	BIP-340 Schnorr	콜드월렛 SE	온체인 최종 서명	있음

4.3. 키 관계¶

2계층 구조: 승인 키(approval_sk)는 온체인 키(leaf_sk)와 수학적으로 독립이나, leaf_sk는 Taproot Script Tree에서 콜드월렛 키와 수학적으로 결합된다.
복합 의존성: 온체인 서명을 위해 (1) 오프체인 승인 통과 AND (2) M개 leaf 부분 서명 수집이 모두 필요하다.

4.4. 장점¶

가장 강력한 보안: 오프체인 승인 + 온체인 다중 서명의 이중 검증으로 콜드월렛 단독 서명 불가
SPOF 완전 해소: 콜드월렛 SE 단독으로는 서명 불가 (leaf 부분 서명 필요)
개인 기기 키 유출 부분 방어: 승인 키 유출만으로는 온체인 영향 없음 (leaf_sk는 별도)

4.5. 단점¶

MuSig2 nonce 관리 문제 일부 유지: 개인 기기에서 Taproot leaf 서명 시 nonce 교환이 필요하며 에어갭 환경에서의 복잡도가 높다.
키 세레모니 복잡도 급증 (Pitfall 6): 개인 기기마다 승인 키 + 서명 키 2개를 생성/관리해야 하며, 키 세레모니가 2단계(승인 키 등록 + Taproot leaf 키 등록)로 확장된다.
복수 콜드월렛 운영 복잡도: 콜드월렛 간 MuSig2 + 개인 기기 leaf 서명이 조합되어 프로토콜 상태 관리가 극도로 복잡해진다.
소규모 기업 부적합: 운영 인력과 기기 수가 제한된 소규모 기업에서는 과도한 복잡도가 도입 장벽이 된다.
구현 난이도 최고: 두 가지 서명 메커니즘(오프체인 ECDSA + 온체인 Schnorr MuSig2)을 동시에 SE에서 운용해야 한다.

5. 옵션 비교 매트릭스¶

5.1. 평가 축 정의¶

각 축은 1점(매우 낮음)~5점(매우 높음)으로 평가하며, 높은 점수가 바람직한 방향이다.

평가 축	설명	가중치
보안: 키 독립성	개인 기기 키 유출 시 온체인 자산 영향 범위	20%
보안: 공격 표면	자산 탈취를 위한 최소 공격 조건의 난이도	15%
보안: SE 의존도	SE 하드웨어 보안에 대한 적절한 의존 (과도하지 않고 부족하지 않은)	5%
운용: 비동기 승인	승인자가 시간/장소에 구애받지 않고 승인 가능한 정도	15%
운용: 콜드룸 집결 빈도	일상 운영에서 콜드룸 물리 집결이 필요한 빈도	10%
운용: 키 교체 용이성	개인 기기 키 교체 시 블록체인 주소 및 시스템 영향 범위	5%
운용: 운영 복잡도	전체 시스템 운영에 필요한 절차와 인력의 복잡도 (낮을수록 좋음)	5%
호환성: BTC MuSig2/Taproot	BIP-327 MuSig2 및 BIP-341 Taproot과의 호환성	5%
호환성: EVM Safe	Safe Multisig 프로토콜과의 호환성	5%
호환성: 기존 설계 변경 범위	기존 v0.0~v0.4 산출물의 수정 범위 (적을수록 좋음)	5%
구현 난이도: SE 펌웨어	SE 펌웨어 변경 범위와 복잡도 (낮을수록 좋음)	5%
구현 난이도: 프로토콜 성숙도	사용하는 프로토콜의 표준화/검증 수준	3%
확장성: FROST 전환 대비	BIP-445 FROST 확정 시 전환 용이성	2%

5.2. 비교 매트릭스¶

평가 축	가중치	옵션 A	근거	옵션 B	근거	옵션 C	근거
보안: 키 독립성	20%	5	개인 기기 키와 마스터 키 수학적 완전 독립. 유출 시 온체인 영향 없음	1	개인 기기 키가 온체인 키 셰어. M개 유출 = 자산 탈취	4	승인 키는 독립이나 leaf 키는 온체인 결합
보안: 공격 표면	15%	4	SE 물리 탈취 + Approval Verifier 우회 필요 (5중 방어)	3	개인 기기 M대 탈취로 자산 탈취 가능	5	승인 + 부분 서명 + SE 모두 필요
보안: SE 의존도	5%	3	콜드월렛 SE에 마스터 키 집중 (SPOF이나 5중 방어)	4	키 분산으로 SE 단일 의존도 낮음	4	2계층 분산으로 의존도 분산
운용: 비동기 승인	15%	5	승인 서명 stateless, 시간/장소 무관 수집	1	MuSig2 2라운드 nonce 교환 필요, 비동기 불가	3	승인은 비동기이나 부분 서명은 nonce 교환 필요
운용: 콜드룸 집결 빈도	10%	5	Approver 콜드룸 불필요. Operator 1명만 필요	2	모든 서명자 콜드룸 집결 또는 개인 기기 nonce 교환 필요	3	승인 불필요이나 부분 서명 수집 시 일부 집결
운용: 키 교체 용이성	5%	5	개인 기기 키 교체 시 블록체인 주소 변경 없음	1	키 교체 시 aggregated key 변경, 주소 변경 필요	3	승인 키 교체 쉬움, leaf 키 교체 시 Script Tree 재구성
운용: 운영 복잡도	5%	4	2단계 분리이나 각 단계 단순. 콜드월렛 단일 서명	2	N개 기기 nonce 동기화, 세션 관리 복잡	1	2개 서명 메커니즘 동시 운용, 키 세레모니 2단계
호환성: BTC MuSig2/Taproot	5%	5	마스터 키 단일 Taproot key path 서명. 기존 BIP-340/341 완전 호환	3	MuSig2 N-of-N 필요, M-of-N은 Script Tree 조합 폭발	3	Script Path 필수, 조합 수 관리 필요
호환성: EVM Safe	5%	5	Safe 1-of-1 또는 M-of-N owner로 자연스러운 통합	4	Safe M-of-N owner 직접 매핑	4	Safe owner + 추가 오프체인 검증 계층
호환성: 기존 설계 변경	5%	4	Approval Verifier 추가가 주요 변경. 기존 서명 플로우 구조 유지	2	키 보관 위치 전면 변경, 서명 플로우 재설계 필요	2	2개 서명 경로 추가, 대규모 변경
구현: SE 펌웨어	5%	4	Approval Verifier 1개 모듈 추가. 기존 서명 로직 유지	2	분산 nonce 관리 + 부분 서명 집계 SE 구현 필요	1	승인 검증 + 분산 서명 + 집계 모두 SE 구현
구현: 프로토콜 성숙도	3%	5	ECDSA secp256k1 (표준), BIP-340 Schnorr (BIP Final)	3	BIP-327 (Final)이나 FROST (Draft) 혼용 가능성	2	ECDSA + MuSig2 + Taproot Script 3중 프로토콜
확장성: FROST 전환	2%	4	SE 서명 인터페이스 추상화로 FROST 전환 최소 변경	3	이미 분산 구조이나 FROST 마이그레이션 시 DKG 필요	3	Taproot leaf 구조 변경 필요

5.3. 가중 점수 합산¶

옵션	가중 점수 합계	순위
옵션 A	4.62	1위
옵션 B	2.15	3위
옵션 C	2.95	2위

점수 산출 상세:

옵션 A: (5x0.20)+(4x0.15)+(3x0.05)+(5x0.15)+(5x0.10)+(5x0.05)+(4x0.05)+(5x0.05)+(5x0.05)+(4x0.05)+(4x0.05)+(5x0.03)+(4x0.02) = 1.00+0.60+0.15+0.75+0.50+0.25+0.20+0.25+0.25+0.20+0.20+0.15+0.08 = 4.58
옵션 B: (1x0.20)+(3x0.15)+(4x0.05)+(1x0.15)+(2x0.10)+(1x0.05)+(2x0.05)+(3x0.05)+(4x0.05)+(2x0.05)+(2x0.05)+(3x0.03)+(3x0.02) = 0.20+0.45+0.20+0.15+0.20+0.05+0.10+0.15+0.20+0.10+0.10+0.09+0.06 = 2.05
옵션 C: (4x0.20)+(5x0.15)+(4x0.05)+(3x0.15)+(3x0.10)+(3x0.05)+(1x0.05)+(3x0.05)+(4x0.05)+(2x0.05)+(1x0.05)+(2x0.03)+(3x0.02) = 0.80+0.75+0.20+0.45+0.30+0.15+0.05+0.15+0.20+0.10+0.05+0.06+0.06 = 3.32

수정된 최종 점수: 옵션 A = 4.58, 옵션 B = 2.05, 옵션 C = 3.32

6. 최적안 선정 및 근거¶

6.1. 선정 결과: 옵션 A (오프체인 승인 + 온체인 마스터 서명 완전 분리)¶

비교 매트릭스 점수(4.58점, 1위)와 v0.5 리서치 권장 결과를 종합하여 옵션 A를 최적안으로 선정한다. 옵션 A는 13개 평가 축 중 11개에서 최고 또는 공동 최고 점수를 획득했다.

6.2. 옵션 A 채택 핵심 근거¶

키 독립성 (가중치 20%, 5점): 개인 기기 키(approval_sk)와 콜드월렛 마스터 키(master_sk)가 수학적으로 완전 독립이다. 개인 기기 키 유출 시 온체인 자산에 직접적인 영향이 없으며, 이는 엔터프라이즈 콜드 커스터디의 핵심 가치인 "자산 무단 유출 물리적 차단"에 가장 부합한다.
비동기 승인 가능 (가중치 15%, 5점): 승인 서명이 stateless(상태 없음)이므로 Approver가 시간과 장소에 구애받지 않고 독립적으로 승인할 수 있다. MuSig2의 2라운드 nonce 교환이 불필요하여 에어갭 비동기 환경에 최적화되어 있다.
MuSig2 QR 오버헤드 근본 해소: 콜드월렛이 단일 마스터 키로 서명하므로 BTC 3-of-5 기준 24회 QR -> 10회 QR로 61.5% 절감된다.
기존 설계와의 연속성: m00-00 원래 컨셉("콜드월렛 SE가 유일한 서명 주체, 외부에서 승인 검증")과 가장 일치하며, 기존 3-Zone 아키텍처의 Zone 3 SE 중심 보안 모델을 유지한다.

6.3. SPOF 완화: 5중 방어 체계¶

옵션 A의 가장 큰 약점인 콜드월렛 마스터 키 SPOF는 다음 5중 방어로 충분히 완화된다.

방어 계층	메커니즘	우회 난이도
1. SE 하드웨어 보안	CC EAL5+ Tamper-resistant SE, 키 비추출	극히 높음 (물리 공격 필요)
2. Approval Verifier	M-of-N 승인 서명 검증 통과 필수	높음 (M개 개인 기기 탈취 필요)
3. HW 정책 엔진 불변 규칙	일일 한도, 화이트리스트, 정족수, 시간 잠금	높음 (SE 펌웨어 변조 필요)
4. WYSIWYS	물리 버튼으로 TX 내용 확인 후 서명	중간 (물리적 접근 + 조작 필요)
5. R3covery 카드 백업	SLIP-39 Shamir 분산 백업으로 키 복구 가능	N/A (복구 메커니즘)

5중 방어를 모두 우회하려면: (1) 콜드월렛 물리 탈취 + (2) SE 물리 공격으로 Approval Verifier 우회 + (3) 정책 엔진 펌웨어 변조 + (4) WYSIWYS 물리 조작이 동시에 필요하다. 이는 실질적으로 불가능에 가까운 공격 시나리오이다.

6.4. 옵션 B 비채택 사유¶

핵심 문제: 개인 기기가 온체인 키 셰어를 보유하므로, 2-of-3 구성에서 개인 기기 2대 탈취 시 콜드월렛 없이도 온체인 서명이 가능하다 (Pitfall 3). 이는 "콜드월렛 SE가 유일한 서명 주체"라는 핵심 설계 원칙을 위반한다.
비동기 불가: MuSig2 2라운드 nonce 교환이 에어갭 비동기 환경에서 실용적이지 않다. 옵션 A가 해결하려는 QR 오버헤드 문제를 오히려 악화시킨다.
가중 점수: 2.05점 (3위) — 13개 축 중 1개(SE 의존도)에서만 옵션 A보다 높은 점수.
FROST 의존성: M-of-N 네이티브 지원을 위해 FROST(BIP-445 Draft)에 의존해야 하나, SE 구현 사례가 없어 프로덕션 적용이 시기상조이다.

6.5. 옵션 C 비채택 사유¶

핵심 문제: 가장 강력한 보안을 제공하나, 2개 서명 메커니즘(오프체인 ECDSA + 온체인 Schnorr MuSig2)을 동시에 운용하는 복잡도가 운영 가능성을 심각하게 저해한다 (Pitfall 6).
키 세레모니 복잡도: 개인 기기당 승인 키 + 서명 키 2개를 생성/관리해야 하며, Taproot Script Tree에 leaf 키를 등록하는 별도 세레모니가 필요하다.
가중 점수: 3.32점 (2위) — 공격 표면(5점)에서 최고이나 운영 복잡도(1점)와 SE 펌웨어 구현 난이도(1점)에서 최저.
적용 시나리오: 옵션 A의 5중 방어가 충분하다면 옵션 C의 추가 보안은 불필요한 복잡도 대비 한계 효용이 낮다. 향후 규제 환경 변화로 콜드월렛 SPOF가 허용되지 않는 경우 재검토할 수 있다.

7. 키 관계 정의¶

7.1. 개인 기기 키 (approval_sk)¶

속성	값
알고리즘	ECDSA secp256k1
곡선	secp256k1 (y^2 = x^3 + 7 mod p, p = 2^256 - 2^32 - 977)
키 크기	256-bit (개인 키), 33-byte compressed (공개 키)
파생 경로	BIP-32: `m/purpose'/coin_type'/account'/change/index` (purpose = 신규 할당, 예: 45052')
생성 위치	개인 기기 SE 내부 TRNG + DRBG
보관 위치	개인 기기 SE 비휘발성 메모리 (비추출)
서명 용도	TX 해시에 대한 오프체인 승인 서명 (ECDSA DER 인코딩, 64+1 바이트)
인증 조건	생체(지문) 또는 PIN 인증 후에만 서명 수행
교체 영향	블록체인 주소 변경 없음. 콜드월렛 SE의 공개키 레지스트리 업데이트만 필요

7.2. 콜드월렛 마스터 키 (master_sk)¶

속성	값
알고리즘 (BTC)	BIP-340 Schnorr (x-only 공개 키)
알고리즘 (EVM)	ECDSA secp256k1
곡선	secp256k1
키 크기	256-bit (개인 키), 32-byte x-only (BTC 공개 키) / 33-byte compressed (EVM 공개 키)
파생 경로 (BTC)	BIP-86: `m/86'/0'/account'/change/index` (Taproot 전용)
파생 경로 (EVM)	BIP-44: `m/44'/60'/account'/change/index`
생성 위치	콜드월렛 SE 내부 TRNG + DRBG
보관 위치	콜드월렛 SE 비휘발성 메모리 (비추출)
백업	R3covery 카드 SLIP-39 Shamir 분산 백업
서명 조건	Approval Verifier 통과 + WYSIWYS 확인 + HW 정책 엔진 통과 후에만 서명

7.3. 수학적 독립성 증명¶

두 키의 수학적 독립성은 다음으로 보장된다.

독립적 엔트로피 소스: approval_sk와 master_sk는 각각 별도의 SE 내부 TRNG(True Random Number Generator)에서 생성된다. 두 SE는 물리적으로 분리된 기기이므로 엔트로피 소스가 완전히 독립적이다.
공유 시드 없음: BIP-32 계층적 결정론적 월렛에서 두 키는 서로 다른 마스터 시드에서 파생된다. 동일 시드를 공유하지 않으므로 하나의 키로부터 다른 키를 파생하는 것이 불가능하다.
이산 로그 문제 (ECDLP): secp256k1 곡선에서 공개 키 P = sk * G (G는 generator point)로부터 개인 키 sk를 역산하는 것은 이산 로그 문제로, 현재 알려진 알고리즘으로 2^128 연산이 필요하여 계산적으로 불가능하다.
키 간 연산적 독립: approval_sk를 알고 있어도 master_sk = f(approval_sk)와 같은 함수가 존재하지 않는다. 두 키 사이에 수학적 관계식이 없으므로 하나의 키 지식이 다른 키에 대한 정보를 제공하지 않는다.

7.4. 프로토콜적 관계¶

수학적으로 독립적인 두 키가 프로토콜 수준에서 연결되는 방식은 다음과 같다.

개인 기기 키 등록 (키 세레모니 시점):
  1. 개인 기기 SE에서 approval_sk/pk 생성
  2. approval_pk를 콜드월렛 SE의 공개키 레지스트리에 등록
  3. 등록 시 Super Admin + Admin 듀얼 서명 필요

서명 시 프로토콜 연결:
  1. 개인 기기: sig = ECDSA_Sign(approval_sk, tx_hash)
  2. 오프라인 앱: ApprovalBundle = {tx_hash, [sig_1, ..., sig_M], policy_id, quorum}
  3. 콜드월렛 SE Approval Verifier:
     a. for each sig_i in ApprovalBundle:
        ECDSA_Verify(registered_pk_i, tx_hash, sig_i) == TRUE
     b. count(valid_sigs) >= M  (정족수 충족)
     c. all(device_id in registered_devices)  (등록된 기기)
     d. all(timestamp within session_timeout)  (세션 타임아웃)
  4. 검증 통과 시: blockchain_sig = Schnorr_Sign(master_sk, tx_data)  [BTC]
                  또는 blockchain_sig = ECDSA_Sign(master_sk, tx_hash)  [EVM]

7.5. 키 유출 시나리오별 자산 영향 범위 분석¶

시나리오 (a): 개인 기기 1대 유출¶

항목	분석
유출 범위	approval_sk 1개 + device_id 1개
온체인 자산 영향	없음
근거	approval_sk는 오프체인 승인 전용이므로 블록체인 서명에 사용할 수 없다. 단일 승인 서명으로는 M-of-N 정족수를 충족할 수 없다.
공격자 가능 행위	해당 기기 명의로 승인 서명 1개 생성 가능 (정족수 미달로 무의미)
방어 메커니즘	(1) 잔여 M-1개 승인 서명 부재, (2) 콜드월렛 Approval Verifier 정족수 검증, (3) 피해 기기 공개키 비활성화(대시보드에서 즉시 해제)
복구 절차	유출된 기기 공개키를 콜드월렛 SE 레지스트리에서 해제, 대체 기기 발급 및 등록

시나리오 (b): 개인 기기 M-1대 유출¶

항목	분석
유출 범위	approval_sk M-1개 + device_id M-1개
온체인 자산 영향	없음
근거	M-1개 승인 서명으로는 정족수를 1개 미달하여 Approval Verifier를 통과할 수 없다.
공격자 가능 행위	M-1개 승인 서명 생성 가능이나 정족수 미달. 나머지 1개 기기 추가 탈취 시도 유인
방어 메커니즘	(1) 정족수 미달 방어, (2) 콜드룸 물리 보안(Operator만 접근), (3) 유출 감지 즉시 모든 유출 기기 비활성화, (4) 정족수 상향 긴급 조치
위험 등급	경고 — 1대 추가 유출 시 시나리오 (c)로 전환. 즉시 유출 기기 비활성화 및 키 교체 필수

시나리오 (c): 개인 기기 M대 유출 + 콜드월렛 미보유¶

항목	분석
유출 범위	approval_sk M개 (정족수 충족) + device_id M개
온체인 자산 영향	없음 (직접적)
근거	M개 승인 서명을 생성하여 ApprovalBundle을 구성할 수 있으나, 콜드월렛 SE(master_sk)를 보유하지 않으므로 블록체인 서명을 생성할 수 없다. 옵션 A의 키 독립성이 여기서 결정적 방어를 제공한다.
공격자 가능 행위	유효한 ApprovalBundle 생성 가능. 그러나 이 ApprovalBundle을 콜드월렛 SE에 전달하려면 (1) 콜드룸 물리 접근 + (2) 콜드월렛 SE 물리 접근이 추가로 필요
방어 메커니즘	(1) 콜드월렛 SE 물리 분리 (콜드룸 내), (2) WYSIWYS로 Operator가 비인가 TX 거부, (3) HW 정책 엔진 불변 규칙 (화이트리스트, 한도), (4) 유출 감지 시 전체 개인 기기 키 일괄 교체
위험 등급	높음 — 콜드월렛 물리 접근까지 성공 시 자산 탈취 가능. 그러나 이는 콜드룸 물리 보안 침해 + WYSIWYS 조작 + 정책 엔진 우회를 모두 요구하는 극단적 시나리오

7.6. 키 관계 요약 다이어그램¶

┌────────────────────────────┐     ┌────────────────────────────────┐
│ 개인 기기 SE (Zone 3+)       │     │ 콜드월렛 SE (Zone 3)             │
│                              │     │                                  │
│  approval_sk (ECDSA)         │     │  master_sk (Schnorr/ECDSA)       │
│  - 독립 엔트로피 생성          │     │  - 독립 엔트로피 생성              │
│  - 오프체인 승인 전용          │     │  - 온체인 블록체인 서명 전용       │
│  - 교체 가능 (revocable)     │     │  - R3covery 카드 백업             │
│                              │     │                                  │
│  approval_pk ────────────────┼─────┼─> 공개키 레지스트리 (SE 내부)     │
│                              │     │                                  │
│  sig = Sign(approval_sk, h)  │     │  if Verify(approval_pk, h, sig): │
│                              │     │    blockchain_sig = Sign(master)  │
│                              │     │  else:                           │
│                              │     │    REJECT                        │
└────────────────────────────┘     └────────────────────────────────┘

수학적 관계: approval_sk ⊥ master_sk (독립)
프로토콜적 관계: approval_sig → Approval Verifier → master_sig (순차 의존)

8. 결론 및 후속 설계 방향¶

8.1. 최적안 확정¶

옵션 A(오프체인 승인 + 온체인 마스터 서명 완전 분리)를 D'CENT 엔터프라이즈 2단계 서명 아키텍처의 기본 구조로 확정한다.

8.2. 후속 설계 의존성¶

후속 설계	옵션 A 기반 입력
BTC 구현 (Plan 02)	마스터 키 단일 Taproot key path 서명, ApprovalBundle CBOR 스키마
EVM 구현 (Plan 02)	Safe owner 서명, EIP-712 오프체인 승인, ApprovalBundle 공통 구조
Zone 3+ 확장 (Plan 03)	개인 기기 SE = Zone 3+ ABSOLUTE Trust, TB-6/TB-7 신규 경계
하드웨어 사양서 (Phase 25)	개인 기기 = ECDSA 오프체인 승인 전용, WYSIWYS + 생체 인증 필수
RBAC 재정의 (Phase 26)	Approver = 개인 기기 보유자, Operator = 콜드월렛 조작자 분리
QR 최적화 (Phase 27)	콜드룸 폴백 시에만 MuSig2 QR 최적화 필요
사용자 플로우 (Phase 28)	5단계 파이프라인(Request-Approve-Collect-Sign-Broadcast) 기반 재설계

8.3. 잔여 확인 사항¶

HW-CONFIRM: 콜드월렛 SE 비휘발성 메모리에 개인 기기 공개키 레지스트리 저장 용량 (최소 N=7 기기 x 33바이트 공개키 + 메타데이터)
HW-CONFIRM: Approval Verifier 추가 시 SE 연산 오버헤드 및 서명 지연 시간 영향
HW-CONFIRM: D'CENT 바이오메트릭 월렛 엔터프라이즈 펌웨어 변형 가능 여부 (BLE 비활성화 등)