v0.5
개인 기기 키 5단계 라이프사이클 설계¶
0. 설계 원칙¶
0.1. 키 독립성 원칙¶
Phase 24-01에서 확정된 옵션 A 아키텍처의 핵심 전제:
- approval_sk(개인 기기 키)와 master_sk(콜드월렛 마스터 키)는 수학적으로 완전 독립
- 두 키는 독립 엔트로피에서 생성되며 공유 시드가 없다
- approval_sk의 개인 키 값으로부터 master_sk를 유도하는 것은 계산적으로 불가능 (이산 로그 문제)
- 따라서 개인 기기 키의 라이프사이클은 콜드월렛 마스터 키와 완전히 독립적으로 운용된다
0.2. 콜드월렛 마스터 키와의 독립성 매핑¶
| 라이프사이클 단계 | approval_sk (개인 기기) | master_sk (콜드월렛) | 상호 영향 |
|---|---|---|---|
| 생성 | SE TRNG 독립 엔트로피 | SE TRNG 독립 엔트로피 | 없음 |
| 백업 | 별도 백업 체계 | Shamir/SLIP-39 | 없음 — 백업 미디어/절차 완전 분리 |
| 교체 | 대시보드 레지스트리 업데이트 | BTC Taproot/EVM Safe owner 변경 | 간접 — 콜드월렛 SE 공개키 레지스트리 갱신 필요 |
| 복구 | 별도 복구 경로 | 별도 복구 경로 | 없음 |
| 폐기 | 대시보드 + 콜드월렛 레지스트리 삭제 | Taproot 주소 재생성 / Safe owner 제거 | 간접 — 정족수 재구성 필요 |
"간접 영향"이란: 콜드월렛 SE의 공개키 레지스트리(approval_pk 목록)를 업데이트해야 하는 운용 절차상의 연계이며, 키 자체의 수학적/암호학적 관계는 없다.
1. 생성 (Generation)¶
1.1. 키 생성 절차¶
┌─────────────────────────────────────────────────────┐
│ 키 생성 절차 (KEY_GENERATE, INS 0x70) │
│ │
│ Step 1: 듀얼 인증 │
│ - 기기 소유자: 지문 인증 │
│ - Admin: 승인 토큰 제출 (키 세레모니 시점) │
│ │
│ Step 2: SE TRNG 엔트로피 생성 │
│ - 256비트 하드웨어 난수 생성 │
│ - 외부 시드 주입 금지 (SE 내부 TRNG 전용) │
│ - 콜드월렛 마스터 키와 무관한 독립 엔트로피 │
│ │
│ Step 3: secp256k1 키 쌍 유도 │
│ - approval_sk = TRNG_output mod n (n = secp256k1 order) │
│ - approval_pk = approval_sk * G │
│ - 키 유효성 검증: 1 < approval_sk < n │
│ │
│ Step 4: 키 ID 생성 │
│ - 형식: {device_id}_{key_index}_{timestamp} │
│ - 예: dcent-bio-001_0_1774746000 │
│ - key_index: 0부터 단조 증가 │
│ │
│ Step 5: NVM 저장 │
│ - approval_sk: NVM 보호 영역 (exportable=false) │
│ - approval_pk: NVM 일반 영역 │
│ - 키 메타데이터: key_id, key_index, generated_at │
│ - key_status: ACTIVE (0x01) │
│ │
│ Step 6: 공개 키 도출 │
│ - approval_pk (compressed, 33바이트) 반환 준비 │
│ - KEY_EXPORT_PUB (INS 0x71)로 외부 조회 가능 │
│ │
│ 출력: approval_pk + key_id + attestation_cert │
└─────────────────────────────────────────────────────┘
1.2. 키 생성 시점¶
| 시점 | 트리거 | 설명 |
|---|---|---|
| 기기 초기 설정 | 관리자 키 세레모니 | 새 기기 배포 시 최초 키 생성 |
| 키 교체 | 관리자 명시적 교체 명령 | 기존 키 비활성화 + 신규 키 생성 (INS 0x70, P1=0x01) |
| 기기 재설정 | 기기 초기화 후 재배포 | 이전 키 소거 후 신규 생성 |
1.3. 대시보드 등록 절차¶
키 생성 후 approval_pk를 대시보드에 등록하여 시스템에서 인식하게 한다.
[1] 개인 기기: KEY_EXPORT_PUB (INS 0x71) → approval_pk + attestation_cert
│
▼ (NFC/QR 에어갭 경유)
[2] 오프라인 앱: 공개 키 수신 → 대시보드 전달용 QR 생성
│
▼ (TB-3 QR 경유)
[3] 대시보드: approval_pk 등록
- attestation_cert 체인 검증 (D'CENT SE 진위 확인)
- 기기 ID + approval_pk 매핑 저장
- Approval Tracker에 기기 활성 상태 등록
│
▼ (TB-3 → TB-4 경유)
[4] 콜드월렛 SE: 공개키 레지스트리에 approval_pk 등록
- Admin + Super Admin 듀얼 서명으로 레지스트리 업데이트
- 등록 최대 N=7 (SE 메모리 제약)
1.4. 콜드월렛 마스터 키와의 관계: 없음¶
| 속성 | approval_sk | master_sk |
|---|---|---|
| 엔트로피 출처 | 개인 기기 SE TRNG | 콜드월렛 SE TRNG |
| BIP 경로 | m/45052'/0'/account'/0/index |
m/86'/0'/account'/0/0 (BTC) |
| 시드 공유 | 없음 | 없음 |
| 수학적 관계 | 독립 (이산 로그로 유도 불가) | 독립 |
| 한쪽 유출 시 영향 | 오프체인 승인만 위조 가능, 온체인 자산 직접 탈취 불가 | 온체인 서명 가능 (단, Approval Verifier 검증 필요) |
2. 백업 (Backup)¶
2.1. 백업 체계 독립성¶
개인 기기 키 백업은 콜드월렛 마스터 키의 Shamir/SLIP-39 백업과 완전히 별도의 체계로 운용한다. 동일 미디어에 두 키를 함께 백업하지 않는다.
2.2. 백업 옵션 비교¶
옵션 A: R3covery 카드 백업¶
v0.3에서 설계한 R3covery 카드 체계를 활용하여 approval_sk를 백업한다.
| 항목 | 평가 |
|---|---|
| 방식 | approval_sk를 SLIP-39 share로 변환, R3covery 카드에 기록 |
| 보안성 | 높음 — R3covery 카드는 NFC 비접촉식, PIN 보호, 카드 분산 보관 |
| 운용성 | 중간 — 별도 R3covery 카드 발급 및 분산 보관 필요 |
| 복구 시간 | 길음 — share 수집 + 키 복원 + SE 주입 절차 |
| 제약 | SE 내부 키를 외부로 추출해야 하므로, 키 생성 시점에만 백업 가능 (이후 추출 불가) |
주요 제약: approval_sk는 SE 내부에서 exportable=false로 보호된다. 따라서 R3covery 카드 백업은 키 생성 시점에 SE가 SLIP-39 share를 직접 계산하여 외부 출력하는 방식으로만 구현 가능하다. 키 생성 후에는 SE 외부로 추출할 수 없다.
옵션 B: 별도 SLIP-39 분산 백업¶
| 항목 | 평가 |
|---|---|
| 방식 | 키 생성 시점에 SE가 SLIP-39 share 생성, 복수 미디어에 분산 |
| 보안성 | 높음 — Shamir 비밀 분산, M-of-N 복원 |
| 운용성 | 낮음 — 별도 share 미디어 관리 부담 (마스터 키 share와 별개로 관리) |
| 복구 시간 | 길음 — share 수집 + 복원 |
| 제약 | 옵션 A와 동일한 SE 추출 제약 |
옵션 C: 백업 불필요 (교체 우선 전략)¶
| 항목 | 평가 |
|---|---|
| 방식 | approval_sk를 백업하지 않고, 기기 분실/고장 시 새 키를 생성하여 교체 |
| 보안성 | 최고 — 키가 SE 외부에 존재하지 않으므로 공격 표면 최소 |
| 운용성 | 높음 — 백업 미디어 관리 불필요, 교체 절차만 사전 정의 |
| 복구 시간 | 중간 — 새 기기 발급 + 키 생성 + 레지스트리 업데이트 (교체 절차) |
| 트레이드오프 | 기존 키 복원 불가. 교체 시 콜드월렛 SE 레지스트리 업데이트 필요 |
2.3. 백업 옵션 종합 비교¶
| 기준 | 옵션 A (R3covery) | 옵션 B (SLIP-39) | 옵션 C (백업 불필요) |
|---|---|---|---|
| 보안성 | ★★★★ | ★★★★ | ★★★★★ |
| 운용성 | ★★★ | ★★ | ★★★★★ |
| 복구 시간 | ★★ | ★★ | ★★★ |
| 관리 부담 | 중간 | 높음 | 최소 |
| SE 구현 복잡도 | 높음 (SLIP-39 SE 구현) | 높음 | 없음 (추가 구현 불필요) |
2.4. 권장 백업 전략: 옵션 C (백업 불필요, 교체 우선)¶
선정 근거:
-
키 독립성 활용: approval_sk는 온체인 자산과 직접 연결되지 않으므로(옵션 A 아키텍처), 키 분실 시 자산 손실이 발생하지 않는다. 새 키를 생성하고 레지스트리를 업데이트하면 된다.
-
최소 공격 표면: 키가 SE 외부에 단 한 번도 존재하지 않으므로, 백업 미디어 탈취/도난으로 인한 키 유출 위험이 원천적으로 제거된다.
-
운용 단순성: 별도 백업 미디어 관리(보관, 접근 통제, 정기 점검)가 불필요하여 운영 비용이 절감된다.
-
SE 구현 단순화: SLIP-39 share 계산을 SE 내부에 구현할 필요가 없으므로 펌웨어 복잡도가 낮아진다. HW-CONFIRM-R06 (SE 내부 SLIP-39 처리 불가 가정)과도 일관된다.
-
N > M 여유: 3-of-5 구성 등에서 기기 2대가 동시 분실되어도 정족수 충족 가능. 교체 완료 전까지 N-1 또는 N-2 상태로 운용.
교체 우선 전략 전제 조건: - 사전에 교체 절차가 문서화되어 있어야 한다 (섹션 3 참조) - N > M 여유분이 확보되어 있어야 한다 (최소 2대 여유 권장) - 긴급 교체 시 새 기기를 신속히 발급할 수 있는 재고 관리 체계 필요
예외: 고보안 기관이 키 연속성을 요구하는 경우, 옵션 A(R3covery 카드 백업)를 선택적으로 적용할 수 있다. 이 경우 키 생성 시점에만 백업이 가능하며, SE 펌웨어에 SLIP-39 share 생성 로직 추가 구현이 필요하다.
3. 교체 (Rotation)¶
3.1. 정기 교체 주기¶
| 항목 | 권장 값 | 근거 |
|---|---|---|
| 정기 교체 주기 | 12개월 | NIST SP 800-57 키 유효 기간 권장, 엔터프라이즈 보안 정책 일반 기준 |
| 최소 교체 주기 | 6개월 | 고보안 기관 요구 시 단축 가능 |
| 최대 교체 주기 | 24개월 | 이 이상은 키 노출 위험 누적 |
| 교체 알림 | 만료 30일 전 대시보드 경고 | 관리자에게 사전 준비 시간 제공 |
3.2. 정기 교체 절차¶
[1] 대시보드: 교체 대상 기기 식별 → 교체 워크플로우 시작
│
▼
[2] 개인 기기: KEY_GENERATE (INS 0x70, P1=0x01 교체 모드)
- 기존 approval_sk_old → SUSPENDED 상태 전환
- SE TRNG → 신규 approval_sk_new 생성
- approval_pk_new 도출
│
▼ (NFC/QR)
[3] 오프라인 앱: 신규 approval_pk_new 수신
│
▼ (TB-3)
[4] 대시보드: 신규 approval_pk_new 등록
- 기존 approval_pk_old: SUSPENDED 표시
- 신규 approval_pk_new: PENDING_ACTIVATION 표시
│
▼ (정족수 변경 승인 — 기존 활성 Approver M-of-N 승인 필요)
[5] 정족수 승인: 다른 활성 Approver들이 키 교체 승인
- 승인 대상: "기기 {device_id}의 approval_pk를 old → new로 교체"
- M-of-(N-1) 승인 필요 (교체 대상 기기 제외)
│
▼ (TB-3 → TB-4)
[6] 콜드월렛 SE: 공개키 레지스트리 업데이트
- approval_pk_old: status → REVOKED (0x03)
- approval_pk_new: status → ACTIVE (0x01)
- Admin + Super Admin 듀얼 서명으로 레지스트리 변경
│
▼
[7] 개인 기기: 기존 키 최종 소거
- approval_sk_old: NVM에서 제로 와이프
- key_status: REVOKED (0x03)
│
▼
[8] 대시보드: 교체 완료 확인 → 감사 로그 기록
3.3. 전이 기간 (Transition Window)¶
키 교체 중 서비스 연속성을 보장하기 위한 전이 기간을 설정한다.
| 항목 | 값 | 설명 |
|---|---|---|
| 전이 기간 | 최대 72시간 (3일) | 교체 시작(Step 2) ~ 완료(Step 7) 사이 |
| 전이 기간 중 유효 키 | 기존 키(SUSPENDED) + 신규 키(PENDING) 둘 다 유효 | 서명 요청 시 두 키 모두 승인 가능 |
| 전이 기간 초과 | 기존 키 강제 폐기, 신규 키만 유효 | 장기 미완료 교체 방지 |
| 전이 기간 중 정족수 | 교체 대상 기기는 기존 키 또는 신규 키 중 하나로만 카운트 (이중 카운트 금지) | 정족수 조작 방지 |
3.4. 체인별 영향¶
BTC (MuSig2/Taproot)¶
| 상황 | 영향 | 대응 |
|---|---|---|
| 단일 콜드월렛 | 영향 없음 — 온체인 서명 키(master_sk)는 변경되지 않음 | 콜드월렛 SE 레지스트리만 업데이트 |
| 복수 콜드월렛 MuSig2 N-of-N | 영향 없음 — MuSig2 키 집합은 콜드월렛 master_sk 기반 | 레지스트리만 업데이트 |
| Taproot 주소 | 변경 없음 — Taproot 주소는 master_pk 기반이며 approval_pk와 무관 | BTC 주소 유지 |
핵심: 옵션 A 아키텍처 덕분에 개인 기기 키 교체 시 BTC Taproot 주소가 변경되지 않는다. 이는 옵션 B(온체인 키 분산)와의 결정적 차이점이다.
EVM (Safe Multisig)¶
| 상황 | 영향 | 대응 |
|---|---|---|
| Safe owner 구성 | 영향 없음 — Safe owner는 콜드월렛 master_sk의 주소이며 approval_pk와 무관 | 콜드월렛 SE 레지스트리만 업데이트 |
| swapOwner TX | 불필요 — approval_pk는 Safe owner가 아니므로 온체인 교체 불필요 | 오프체인 레지스트리만 업데이트 |
| 가스비 | 발생 없음 — 온체인 트랜잭션 불필요 | 비용 제로 |
핵심: EVM에서도 개인 기기 키 교체는 온체인 트랜잭션 없이 완료된다. swapOwner가 불필요하므로 교체 비용이 제로이다.
3.5. 비상 교체 (기기 분실/훼손)¶
[비상 교체 트리거]
- 기기 분실 신고
- 기기 물리적 파손
- 인증 실패 잠금(10회) 발동
- 보안 사고 감지
[비상 교체 절차]
1. 대시보드: 분실 기기의 approval_pk를 즉시 SUSPENDED 처리
- 해당 기기의 승인 서명은 더 이상 유효하지 않음
- 정족수: N-1 상태로 전환 (예: 3-of-5 → 3-of-4)
2. 정족수 영향 평가:
- M <= (N-1): 정상 운용 가능 → 교체 우선순위 보통
- M > (N-1): 정족수 미달 위험 → 교체 우선순위 긴급
- M = N: 즉시 교체 불가 → 콜드룸 직접 서명 폴백
3. 신규 기기 발급:
- 재고에서 새 기기 배포
- KEY_GENERATE (INS 0x70, P1=0x00 신규)
- 대시보드 + 콜드월렛 SE 레지스트리 등록
4. 분실 기기 최종 폐기:
- 대시보드 + 콜드월렛 SE에서 기존 approval_pk REVOKED 처리
- 분실 기기가 발견되더라도 해당 키는 더 이상 유효하지 않음
4. 복구 (Recovery)¶
4.1. 복구와 교체의 차이¶
| 구분 | 복구 (Recovery) | 교체 (Rotation) |
|---|---|---|
| 정의 | 동일한 approval_sk를 새 기기에 복원 | 새 approval_sk를 생성하여 기존 키를 대체 |
| 전제 | 키 백업이 존재해야 함 | 백업 불필요 |
| 결과 | 동일 키 ID, 동일 공개 키 | 새 키 ID, 새 공개 키 |
| 레지스트리 | 업데이트 불필요 (동일 키) | 업데이트 필요 (키 교체) |
| 온체인 영향 | 없음 | 없음 (옵션 A) |
4.2. 백업 전략별 복구 절차¶
옵션 C (권장: 백업 불필요) → 복구 불가, 교체로 폴백¶
옵션 C(백업 불필요)를 채택한 경우, 동일 키 복구는 불가능하다. 기기 분실/고장 시 섹션 3.5의 비상 교체 절차를 따른다.
기기 분실/고장
│
▼
복구 가능? → 아니오 (옵션 C: 백업 없음)
│
▼
교체 절차 실행 (섹션 3.5)
- 신규 기기 발급 → 신규 키 생성 → 레지스트리 업데이트
옵션 A (선택적: R3covery 카드 백업) → 복구 가능¶
고보안 기관이 옵션 A를 선택한 경우의 복구 절차:
[1] R3covery 카드 share 수집
- SLIP-39 M-of-N share 중 M개 이상 수집
- 물리적으로 분산 보관된 카드를 안전한 장소에 집결
[2] approval_sk 복원
- SLIP-39 share → approval_sk 복원
- 새 기기 SE에 키 주입 (키 세레모니 환경)
- 주입 후 share는 즉시 폐기 (메모리에서 삭제)
[3] 대시보드 재인증
- 새 기기의 SE attestation 검증
- 동일 approval_pk 확인 (공개 키 일치)
- device_id는 새 기기로 업데이트
[4] 콜드월렛 SE 확인
- 레지스트리의 approval_pk는 동일하므로 변경 불필요
- device_id만 업데이트 (Admin 승인)
4.3. 복구 불가 시 폴백 경로¶
복구 시도 실패 (share 부족, 미디어 손상 등)
│
▼
교체 절차로 폴백 (섹션 3.5 비상 교체)
│
├── 기존 approval_pk: REVOKED 처리
├── 신규 기기: 신규 approval_sk 생성
└── 레지스트리: 신규 approval_pk 등록
5. 폐기 (Revocation)¶
5.1. 폐기 사유¶
| 사유 | 긴급도 | 설명 |
|---|---|---|
| 직원 퇴사 | 보통 | 퇴사 시점에 기기 회수 및 키 폐기 |
| 역할 변경 | 보통 | Approver 역할 해제 시 키 폐기 |
| 기기 분실 | 높음 | 즉시 SUSPENDED → 교체 완료 후 REVOKED |
| 보안 사고 | 긴급 | 즉시 REVOKED + 정족수 재구성 |
| 기기 고장 | 보통 | 기기 접근 가능 시 정상 폐기, 불가 시 원격 폐기 |
| 정기 교체 | 낮음 | 신규 키 활성화 후 기존 키 폐기 |
5.2. 정상 폐기 절차 (기기 접근 가능)¶
[1] 관리자: 폐기 결정 및 대시보드에서 폐기 워크플로우 시작
[2] 정족수 승인: 기존 활성 Approver M-of-(N-1) 폐기 승인
[3] 개인 기기: DEVICE_DEREGISTER (INS 0x61, P1=0x00 정상 폐기)
- 듀얼 인증: 기기 소유자 지문 + Admin 승인 토큰
- SE 내부 처리:
a. approval_sk → 제로 와이프 (0x00으로 덮어쓰기, 복구 불가)
b. 키 메타데이터 삭제
c. key_status → REVOKED (0x03)
d. 감사 로그: {action: REVOKE, timestamp, admin_token_hash}
[4] 대시보드: approval_pk 폐기 등록
- 상태: REVOKED
- 폐기 사유, 폐기 시간, 승인자 목록 기록
[5] 콜드월렛 SE: 공개키 레지스트리 업데이트
- approval_pk: status → REVOKED (0x03)
- 이후 해당 공개 키의 승인 서명은 Approval Verifier에서 거부
- Admin + Super Admin 듀얼 서명
[6] 정족수 재구성:
- N → N-1
- M 유지 가능 여부 확인 (M <= N-1이면 유지, M > N-1이면 M 조정 또는 신규 기기 추가)
5.3. 체인별 폐기 영향¶
BTC (Taproot)¶
| 상황 | 영향 | 대응 |
|---|---|---|
| 단일 콜드월렛 | Taproot 주소 변경 없음 — master_pk는 불변 | 콜드월렛 SE 레지스트리에서 폐기 키 제거만 |
| 복수 콜드월렛 | Taproot 주소 변경 없음 — MuSig2 키 집합은 master_sk 기반 | 레지스트리 업데이트만 |
옵션 A 아키텍처에서 개인 기기 키 폐기는 BTC 온체인에 어떤 영향도 미치지 않는다. Taproot 주소는 master_pk로 결정되며 approval_pk와 무관하다.
EVM (Safe Multisig)¶
| 상황 | 영향 | 대응 |
|---|---|---|
| Safe owner 구성 | removeOwner 불필요 — approval_pk는 Safe owner가 아님 | 콜드월렛 SE 레지스트리에서 폐기 키 제거만 |
| 가스비 | 발생 없음 | 온체인 트랜잭션 불필요 |
EVM에서도 개인 기기 키 폐기는 removeOwner 트랜잭션 없이 완료된다. 오프체인 레지스트리 업데이트만으로 충분하다.
5.4. 원격 폐기 (기기 접근 불가)¶
기기가 분실되어 물리적 접근이 불가능한 경우의 폐기 절차:
[원격 폐기 절차]
[1] 관리자: 대시보드에서 원격 폐기 워크플로우 시작
- 대상: 접근 불가 기기의 approval_pk
[2] 정족수 승인: 기존 활성 Approver M-of-(N-1) 원격 폐기 승인
[3] 대시보드: approval_pk 즉시 REVOKED 처리
- 해당 공개 키로 생성된 승인 서명은 이후 무효
[4] 콜드월렛 SE: 공개키 레지스트리에서 해당 키 REVOKED 처리
- Admin + Super Admin 듀얼 서명
[5] 정족수 재구성 (섹션 5.2 Step 6과 동일)
[주의사항]
- 기기 SE 내부의 approval_sk는 물리적으로 삭제되지 않음 (기기 접근 불가)
- 그러나 해당 키로 생성된 서명은 콜드월렛 Approval Verifier에서 거부됨 (REVOKED 키)
- 따라서 기기 탈취 후 approval_sk로 서명해도 시스템에서 승인 불가
- 추가 방어: 기기 자체의 지문/PIN 인증 + 10회 실패 와이프
5.5. 폐기 감사 로그 요구사항¶
| 항목 | 요구사항 | 보존 기간 |
|---|---|---|
| 폐기 사유 | 퇴사/역할변경/분실/보안사고/교체/고장 | 영구 |
| 폐기 시간 | ISO 8601 타임스탬프 | 영구 |
| 폐기 승인자 | 정족수 승인에 참여한 Approver 목록 | 영구 |
| 폐기 유형 | 정상(기기 접근)/원격(기기 미접근) | 영구 |
| 대상 키 ID | {device_id}{key_index} | 영구 |
| 대상 approval_pk | 폐기된 공개 키 (추적용) | 영구 |
폐기 감사 로그는 대시보드 데이터베이스에 영구 보존한다. 콜드월렛 SE 내부 감사 로그(50건 순환)에도 폐기 이벤트가 기록되나, 영구 보존은 대시보드가 담당한다.
6. 라이프사이클 상태 다이어그램¶
6.1. 상태 전이도¶
KEY_GENERATE
(INS 0x70, P1=0x00)
+ 듀얼 인증
┌────────────┐ ─────────────────▶ ┌────────────┐
│ INACTIVE │ │ ACTIVE │
│ (미생성) │ │ (운용 중) │
└────────────┘ └─────┬──────┘
│
┌──────────────────────┼──────────────────────┐
│ │ │
정기 교체 시작 보안 사고/분실 직원 퇴사
(INS 0x70, P1=0x01) (관리자 명령) 역할 변경
│ │ │
▼ ▼ │
┌────────────┐ ┌────────────┐ │
│ ROTATING │ │ SUSPENDED │ │
│ (교체 진행) │ │ (일시 중지) │ │
└──────┬─────┘ └──────┬─────┘ │
│ │ │
신규 키 활성화 교체 완료 또는 │
기존 키 폐기 폐기 결정 │
│ │ │
▼ ▼ ▼
┌────────────┐ ┌────────────────────────────┐
│ ACTIVE │ │ REVOKED │
│ (신규 키) │ │ (폐기됨 — 복구 불가) │
└────────────┘ └────────────────────────────┘
6.2. 상태 전이 상세¶
| 전이 | 트리거 | 필요 권한 | 영향 범위 |
|---|---|---|---|
| INACTIVE → ACTIVE | KEY_GENERATE (INS 0x70) | 기기 소유자 + Admin (듀얼 인증) | 대시보드 등록, 콜드월렛 SE 레지스트리 추가 |
| ACTIVE → ROTATING | 정기 교체 시작 | Admin (교체 워크플로우 시작) | 전이 기간 시작 (72시간 제한) |
| ROTATING → ACTIVE (신규) | 신규 키 활성화 + 기존 키 폐기 | M-of-(N-1) 정족수 승인 | 콜드월렛 SE 레지스트리 갱신 |
| ACTIVE → SUSPENDED | 기기 분실/보안 사고 | Admin (즉시) | 해당 키 승인 서명 임시 무효 |
| SUSPENDED → REVOKED | 폐기 결정 | M-of-(N-1) 정족수 승인 | 콜드월렛 SE 레지스트리에서 영구 제거 |
| SUSPENDED → ACTIVE | 기기 회수/오인 신고 | Admin + 기기 소유자 확인 | 승인 서명 재유효화 |
| ACTIVE → REVOKED | 직원 퇴사/역할 변경 | M-of-(N-1) 정족수 승인 | SE 키 소거 + 레지스트리 영구 제거 |
6.3. 상태별 승인 서명 유효성¶
| 상태 | 승인 서명 생성 가능 | 콜드월렛 Approval Verifier 수용 | 비고 |
|---|---|---|---|
| INACTIVE | X | X | 키 미생성 |
| ACTIVE | O | O | 정상 운용 |
| ROTATING | O (기존 키 또는 신규 키) | O (둘 중 하나만 카운트) | 전이 기간 |
| SUSPENDED | X (기기 잠금) | X | 임시 무효 |
| REVOKED | X (키 소거됨) | X | 영구 폐기 |
설계 기준: option-evaluation.md approval_sk 독립성 원칙 기반 라이프사이클 설계 참조: zone3plus-security-architecture.md 키 라이프사이클 정의 참조: btc-implementation.md Taproot 주소 구조, evm-implementation.md Safe owner 구조 보안 참조: NIST SP 800-57 키 관리 권장사항
관련 문서¶
- 개인 서명 기기 적합성 평가 및 최소 하드웨어 요구사항 -- 펌웨어 요구사항
- 엔터프라이즈 펌웨어 요구사항 -- 펌웨어 요구사항