콘텐츠로 이동

v0.0

MPC-TSS 웜 월렛 계층 설계서

1. Executive Summary

본 문서는 D'CENT 엔터프라이즈의 웜 월렛 계층에 적용되는 MPC-TSS(Multi-Party Computation — Threshold Signature Scheme) 기반 서명 시스템을 설계한다. MPC-TSS는 프라이빗 키를 여러 서버에 분산된 키 셰어(Key Share)로 나누어, 전체 키가 단일 지점에서 재구성되지 않으면서도 임계값(t) 이상의 셰어 참여로 유효한 서명을 생성하는 암호학적 프로토콜이다.

1.1. 웜 월렛에 MPC-TSS를 채택하는 이유

요구사항 MPC-TSS 해결 방식
에어갭 없이도 키 보호 전체 키가 존재하지 않음 → 단일 서버 해킹으로 키 탈취 불가
빠른 서명 온라인 통신으로 1-3초 내 서명 완성
셀프 커스터디 유지 D'CENT가 어떤 셰어도 보유하지 않음
크로스체인 호환 체인 무관 단일 서명 출력 (ECDSA/EdDSA)
유연한 쿼럼 t-of-n 구성으로 M-of-N 다중 서명 구현

1.2. Cold Tier와의 관계

Cold Tier (에어갭)          Warm Tier (온라인)
┌──────────────────┐       ┌──────────────────┐
│  MuSig2 (BTC)    │       │  MPC-TSS          │
│  Safe (EVM)      │       │  (ECDSA/EdDSA)    │
│                  │       │                    │
│  하드웨어 SE 서명  │       │  소프트웨어 분산 서명 │
│  에어갭 다중 서명  │       │  온라인 임계 서명    │
│  3중 정책 방어    │       │  SW 정책만          │
│                  │       │                    │
│  장기 보관 (80-95%)│       │  일상 운영 (5-15%)  │
└──────────────────┘       └──────────────────┘

원칙: MPC-TSS는 Warm Tier에만 적용된다. Cold Tier의 에어갭 원칙(MuSig2/Safe)은 절대 변경되지 않는다.


2. MPC-TSS 프로토콜 선택

2.1. 후보 프로토콜 비교

항목 GG20 CGGMP21 Lindell 2022
논문 Gennaro-Goldfeder 2020 Canetti-Gennaro-Goldwasser-Maier-Pinkas 2021 Lindell 2022
서명 알고리즘 ECDSA ECDSA ECDSA
라운드 수 (DKG) 5 라운드 4 라운드 3 라운드
라운드 수 (서명) 6 라운드 4 라운드 3 라운드
통신 복잡도 O(n²) O(n²) O(n)
서명 시간 (3-of-5) ~500ms ~300ms ~200ms
Identifiable Abort 미지원 지원 미지원
악의적 참여자 대응 제한적 식별 가능 제한적
보안 증명 UC 모델 UC 모델 (강화) 독립 증명
오픈소스 구현 tss-lib (Binance) multi-party-ecdsa (ZenGo) 제한적

2.2. 프로토콜 선택: CGGMP21

선택 근거:

기준 CGGMP21 선택 이유
Identifiable Abort 악의적 참여자를 식별하여 배제 가능 → 엔터프라이즈 필수
보안 강도 UC(Universal Composability) 모델 강화 증명 → 학술적 검증 완료
성능 GG20 대비 서명 라운드 감소 (6→4) → 지연 시간 개선
생태계 ZenGo, DFNS, Cobo 등 주요 업체 채택 → 검증된 실적

2.3. t-of-n 임계값 구성

구성 적합 시나리오 안전 마진 가용성
2-of-3 소규모 기업, 기본 운영 1 서버 다운 가능 67% 가용
3-of-5 중견 기업, 표준 운영 2 서버 다운 가능 60% 가용
4-of-7 대기업, 고보안 운영 3 서버 다운 가능 57% 가용
5-of-9 기관 투자자, 최고 보안 4 서버 다운 가능 56% 가용

권장: 대부분의 엔터프라이즈에 3-of-5 구성을 기본 권장. 보안과 가용성의 최적 균형.

2.4. 키 리프레시 (Proactive Secret Sharing)

MPC-TSS의 핵심 장점 중 하나인 키 리프레시(Key Refresh) 지원:

항목 설명
원리 동일한 공개키/주소를 유지하면서 키 셰어를 새 값으로 교체
효과 과거 유출된 셰어가 무효화됨 → 시간 경과에 따른 보안 강화
주기 기본 7일 (설정 가능: 1일~30일)
절차 자동 실행 (관리자 승인 불필요, 감사 로그만 기록)
영향 온체인 주소 변경 없음, 서비스 중단 없음

3. 키 셰어 분산 구조

3.1. 셰어 보관 위치

기업 인프라 (5개 서버 — 3-of-5 구성)

서버 A (서울 IDC)     서버 B (서울 IDC 2)    서버 C (부산 IDC)
┌───────────────┐    ┌───────────────┐     ┌───────────────┐
│ KeyShare #1    │    │ KeyShare #2    │     │ KeyShare #3    │
│ (암호화 저장)  │    │ (암호화 저장)   │     │ (암호화 저장)  │
│ HSM 보호       │    │ HSM 보호       │     │ HSM 보호       │
└───────────────┘    └───────────────┘     └───────────────┘

서버 D (싱가포르)      서버 E (도쿄)
┌───────────────┐    ┌───────────────┐
│ KeyShare #4    │    │ KeyShare #5    │
│ (암호화 저장)  │    │ (암호화 저장)   │
│ HSM 보호       │    │ HSM 보호       │
└───────────────┘    └───────────────┘

지리적 분산 권장: - 최소 2개 이상의 물리적 위치에 분산 - 동일 관할권 집중 방지 (법적 압류 리스크 완화) - 각 서버는 독립적인 네트워크/전원/운영

3.2. D'CENT 셰어 미보유 원칙

항목 정책
D'CENT 셰어 보유 절대 없음 — 모든 셰어는 기업 인프라에만 존재
D'CENT 서버 참여 절대 없음 — 서명 프로토콜에 D'CENT 인프라 관여 없음
D'CENT 데이터 접근 절대 없음 — 셰어 데이터, 서명 데이터 전송 없음

이는 셀프 커스터디 원칙(self-custody-architecture.md)을 Warm Tier에서도 동일하게 적용하는 것이다.

3.3. 셰어 보호

보호 수준 방식 비고
HSM 보호 (권장) FIPS 140-3 Level 3 HSM 내부에 셰어 저장 최고 보안, 비용 높음
SW 암호화 AES-256-GCM + 서버별 마스터 키(PBKDF2) 중간 보안, 비용 낮음
최소 디스크 암호화 (LUKS) + 접근 통제 기본 보안

3.4. 셰어 로테이션 절차

정기 셰어 로테이션 (키 리프레시와 동시 수행):

[1] 로테이션 스케줄 도래 (기본 7일)
[2] 모든 참여 서버 가용성 확인 (t개 이상 필요)
[3] CGGMP21 Key Refresh 프로토콜 실행
     ├─ 4 라운드 인터랙티브 프로토콜
     ├─ 각 서버가 새 셰어 생성
     └─ 이전 셰어 안전 삭제 (제로 필)
[4] 새 셰어로 테스트 서명 수행 (검증)
[5] 감사 로그 기록 (로테이션 완료, 참여 서버, 타임스탬프)

4. 서명 프로토콜

4.1. 키 생성 세레모니 (DKG: Distributed Key Generation)

DKG 세레모니:

[사전 준비]
 - n개 서버 배포 완료 (네트워크 연결, HSM 설정)
 - 서버 간 상호 TLS 인증 구성
 - Admin 쿼럼 승인 (DKG 시작 권한)

[DKG 실행] (CGGMP21 DKG — 4라운드)
 Round 1: 각 서버가 VSS(Verifiable Secret Sharing) 커밋먼트 생성 + 브로드캐스트
 Round 2: 각 서버가 Feldman VSS 셰어를 다른 서버에 전달 (포인트-투-포인트)
 Round 3: 각 서버가 수신 셰어 검증 + Schnorr 증명 생성
 Round 4: 공개키 집계 → 최종 공개키 확정 + 각 서버 셰어 저장

[DKG 결과]
 ├─ 공개키(집계): 모든 서버 + 대시보드에 공유
 ├─ 개별 셰어: 각 서버에만 저장 (외부 전달 없음)
 └─ 체인별 주소 파생: 공개키 → BTC/ETH/등 체인 주소

[검증]
 - 테스트 서명 실행 (t개 서버 참여)
 - 블록체인에서 서명 유효성 확인
 - DKG 세레모니 전 과정 감사 로그

4.2. 서명 요청 흐름

[1] 서명 요청 수신 (대시보드 → 서명 코디네이터)
     ├─ 트랜잭션 데이터 (수신자, 금액, 체인)
     ├─ 정책 검증 결과 (대시보드에서 사전 검증 완료)
     └─ 세션 ID 생성

[2] 서명 참여자 선택 (t개 서버)
     ├─ 가용한 서버 중 t개 선택 (라운드 로빈 또는 지연 시간 기반)
     └─ 참여자에게 서명 세션 초대

[3] CGGMP21 서명 프로토콜 (4라운드)
     Round 1: 각 참여자가 커밋먼트 생성 + 브로드캐스트
     Round 2: 부분 서명 생성 + 브로드캐스트
     Round 3: 부분 서명 검증 + 집계 준비
     Round 4: 최종 서명 집계 → 유효한 ECDSA/EdDSA 서명 출력

[4] 서명 결과 반환
     ├─ 유효한 서명 → 대시보드로 반환
     ├─ 실패 시 → 에러 코드 + Identifiable Abort (악의적 참여자 식별)
     └─ 감사 로그 기록 (참여자, 서명 해시, 소요 시간)

[5] 트랜잭션 전파
     - 대시보드가 블록체인에 전파 (Cold Tier와 동일한 전파 경로)

4.3. 통신 채널 보안

보안 계층 구현
전송 암호화 TLS 1.3 (모든 서버 간 통신)
상호 인증 mTLS (클라이언트 + 서버 인증서)
메시지 무결성 HMAC-SHA256 (프로토콜 메시지별)
리플레이 방지 세션 ID + 메시지 시퀀스 번호
네트워크 격리 전용 VPN 또는 Private Network

4.4. 서명 지연 시간 목표

구성 DKG 시간 서명 시간 비고
3-of-5 (동일 리전) ~2초 < 500ms 목표 충족
3-of-5 (글로벌 분산) ~5초 < 2초 네트워크 지연 포함
5-of-9 (글로벌 분산) ~10초 < 3초 목표 상한

5. 정책 기반 자동화

5.1. 자동 서명 조건

정책 범위 내 트랜잭션은 인간 승인 없이 MPC-TSS가 자동 서명:

자동 서명 조건 (모든 조건 AND):

[1] 금액 < Warm 건당 한도 (예: $10,000)
    AND
[2] 수신 주소가 화이트리스트 등록
    AND
[3] 영업시간 내 (설정된 시간대)
    AND
[4] 일일 누적 < Warm 일일 한도
    AND
[5] 비상 정지(Kill Switch) 비활성 상태

5.2. 자동 서명 불가 시 에스컬레이션

자동 서명 조건 미충족
    │
    ├─ 금액 초과 (Warm 한도) → Cold Tier 에스컬레이션
    │   └─ 에어갭 다중 서명 프로세스로 전환
    │
    ├─ 화이트리스트 미등록 → 요청 거부 + 등록 안내
    │
    ├─ 영업시간 외 → 대기 큐 (다음 영업시간 처리)
    │   └─ 긴급: Admin 승인 시 시간 제한 해제
    │
    └─ 일일 한도 초과 → 요청 거부 + 익일 자동 리셋 대기

5.3. 비상 정지 (Kill Switch)

항목 설명
발동 조건 관리자 수동 발동 / 이상 패턴 감지 자동 발동
효과 Warm 월렛 전체 서명 즉시 중단
범위 모든 자동 서명 + 수동 서명 차단
해제 Admin 쿼럼 (3-of-5) 승인 필요
연동 비상 환수(tiered-custody-architecture.md) 자동 트리거

5.4. 이상 패턴 감지 (자동 Kill Switch 트리거)

이상 패턴 임계값 자동 조치
단시간 대량 서명 1분 내 10건 초과 Kill Switch + 알림
비정상 금액 패턴 평소 평균의 5배 초과 금액 Kill Switch + 알림
서명 실패 연속 5회 연속 실패 일시 중단 + 알림
미등록 주소 반복 시도 10분 내 3회 일시 중단 + 알림

6. 콜드월렛 MuSig2와의 관계

6.1. 서명 방식 공존 구조

계층 BTC EVM Cross-chain
Cold Tier MuSig2 (BIP-327) Safe Multisig 각 체인 네이티브
Warm Tier MPC-TSS (ECDSA) MPC-TSS (ECDSA) MPC-TSS (통합)

6.2. 동일 자산의 계층 간 이동 시 주소 체계

이동 방향 출발 주소 도착 주소 서명 방식
Cold→Warm MuSig2 집계키 주소 (Taproot) MPC-TSS 공개키 주소 MuSig2 (에어갭)
Warm→Cold MPC-TSS 공개키 주소 MuSig2 집계키 주소 (Taproot) MPC-TSS (온라인)
Warm→External MPC-TSS 공개키 주소 외부 수신 주소 MPC-TSS (온라인)

6.3. 주소 관리

  • Cold 주소와 Warm 주소는 완전히 분리된 키 세트에서 파생
  • 대시보드에서 Cold/Warm 주소를 구분하여 관리
  • 내부 이체(Cold↔Warm)는 자동 화이트리스트 등록 (내부 주소)
  • 외부에서는 Cold 주소와 Warm 주소의 관계를 알 수 없음 (프라이버시)

7. 보안 고려사항

7.1. 셰어 서버 해킹 시 영향 범위

해킹 범위 영향 대응
1개 서버 (< t) 영향 없음 — 서명 불가 해당 서버 격리 + 키 리프레시
t-1개 서버 서명 불가 — 가용성만 저하 즉시 키 리프레시 + 서버 교체
t개 이상 서버 서명 가능 — 자산 위험 Kill Switch + 비상 환수 + 키 교체

7.2. 인사이더 위협 대응

대응 방안 설명
직무 분리 각 셰어 서버의 Admin이 다른 사람
셰어 보유자 독립 셰어 서버 운영자가 Cold Tier 서명자와 겹치지 않음
감사 로그 모든 서명 요청/응답 기록, 변조 불가
키 리프레시 정기 로테이션으로 과거 셰어 무효화
이상 패턴 감지 자동 Kill Switch로 대량 유출 방지

7.3. 가용성

구성 허용 장애 서버 가용성
3-of-5 2개 서버 다운 가능 99.9% (각 서버 99%)
4-of-7 3개 서버 다운 가능 99.99%
5-of-9 4개 서버 다운 가능 99.999%

8. 오픈소스 / 감사 전략

8.1. CLAUDE.md 원칙 준수

CLAUDE.md의 "What NOT to Use" 원칙: "Single-vendor MPC without open audit — 독점 MPC 구현은 금지"

전략 설명 권장도
오픈소스 라이브러리 활용 + 외부 감사 검증된 라이브러리를 사용하고 독립 감사 기관이 감사 권장
자체 구현 + 외부 감사 CGGMP21 논문 기반 자체 구현, 외부 감사 위탁 가능 (비용 높음)
단일 벤더 MPC 도입 특정 벤더의 독점 MPC 솔루션 금지

8.2. 오픈소스 라이브러리 평가

라이브러리 프로토콜 언어 감사 이력 유지보수 권장
tss-lib (Binance) GG20 Go Kudelski 감사 완료 활발 후보 (GG20 기반)
multi-party-ecdsa (ZenGo) GG20/CGGMP21 Rust Trail of Bits 감사 활발 권장
Webb tss-lib GG20 Rust 커뮤니티 감사 중간 대안
Thorchain TSS GG20 Go Halborn 감사 중간 참조

8.3. 권장 전략

Phase 1 (출시):
  multi-party-ecdsa (ZenGo) 기반 구현
  + 커스텀 레이어 (정책 연동, 감사 로그, Kill Switch)
  + 외부 감사 (Trail of Bits 또는 동급)

Phase 2 (강화):
  CGGMP21 최적화 구현 (성능 개선)
  + 정기 감사 (연 1회)
  + 침투 테스트 (반기 1회)

8.4. 감사 대상

감사 영역 범위 주기
키 생성 (DKG) VSS 커밋먼트, 셰어 분배, 검증 출시 전 + 연 1회
서명 프로토콜 부분 서명 생성/검증, 집계, Abort 처리 출시 전 + 연 1회
키 리프레시 셰어 로테이션, 이전 셰어 삭제 출시 전 + 연 1회
통신 보안 TLS 구성, mTLS, 리플레이 방지 반기 1회
정책 연동 자동 서명 조건 검증, Kill Switch 반기 1회

9. Phase 5 시스템 아키텍처 연계 포인트

연계 항목 Phase 5 상세화 범위
서명 코디네이터 서명 요청 라우팅, 참여자 선택, 세션 관리 아키텍처
셰어 서버 배포 컨테이너 구성, HSM 인터페이스, 네트워크 설정
정책 연동 인터페이스 대시보드 정책 엔진 → 서명 코디네이터 API
Kill Switch 구현 신호 전파 메커니즘, 서명 즉시 중단 로직
모니터링 셰어 서버 상태, 서명 성공률, 이상 패턴 메트릭
DKG 세레모니 도구 관리자용 DKG 실행 CLI/웹 인터페이스

본 문서는 Phase 4 Differentiation & Extended Architecture의 일부로, MPC-TSS 기반 웜 월렛 계층을 설계한다. CLAUDE.md의 "What NOT to Use"(단일 벤더 MPC 금지) 원칙을 준수하며, Phase 3 다중 서명 워크플로우(multisig-workflow.md)의 MPC-TSS 확장 방향을 구체화한다.


관련 문서