v0.6
규제 태그 비트맵 CDDL 스키마 및 SE 불변 규칙 매핑¶
1. 개요¶
1.1. 설계 목적¶
본 문서는 SE(Secure Element, Zone 3)의 불변 규칙 각각이 어떤 규제 조항을 충족하는지 비트맵으로 표현하여 서명 증적에 포함하는 RegulationTagBitmap 구조를 설계한다. 이를 통해 하드웨어 수준에서 규제 준수를 추적 가능하게 하고, Phase 32 컴플라이언스 보고서의 자동 생성 기반을 마련한다.
핵심 가치: - 모든 서명 증적에 "이 서명이 어떤 규제 조항을 충족했는지" 비트맵이 포함됨 - SE NVM에 규제 태그를 저장하여 하드웨어 레벨에서 규제 추적 가능 - 감사인이 특정 서명에 대해 어떤 규제 정책이 적용되었는지 즉시 확인 가능
1.2. 규제 근거¶
| 요건 | 근거 | 본 문서 대응 |
|---|---|---|
| POL-01 | SE 불변 규칙에 규제 태그 비트맵 추가 | RegulationTagBitmap CDDL + 비트 할당표 |
| CORE-09 | 정책 변경 이력 관리 | 규제 태그 변경 시 before/after 비트맵 기록 |
| REG-KR-11 | ISMS-P 접근 통제 | RBAC + 쿼럼 규칙에 규제 태그 매핑 |
| REG-EU-01 | MiCA 거버넌스 체계 | 정책 규칙별 규제 조항 추적 가능 |
1.3. Phase 30 연결점¶
본 문서는 Phase 30에서 정의된 다음 구조를 기반으로 확장한다:
- SEAuditDigest (128B 고정):
reserved(3B)필드를 규제 태그 요약 인덱스로 활용 - AuditRecord.payload:
PolicyChangePayload에 규제 태그 before/after 비트맵 포함 - SE NVM 레이아웃: v0.6 기준 ~3.84KB, 확장 여유 ~12.16KB
2. RegulationTagBitmap CDDL 스키마¶
2.1. CDDL 정의¶
; ====================================================================
; D'CENT Enterprise RegulationTagBitmap Schema
; CBOR (RFC 8949) encoded
; SE NVM에 저장되는 규제 조항 매핑 비트맵
; Phase: 31-hardware-policy-engine
; ====================================================================
RegulationTagBitmap = bstr .size 8 ; 64 bits (8 bytes)
; 비트맵 해석:
; - 각 비트는 특정 규제 조항에 매핑
; - 1 = 해당 규제 충족 강제 (활성), 0 = 비적용 (비활성)
; - Big-endian 비트 순서: 비트 0 = MSB of byte 0
; SE 규칙 테이블에 추가되는 필드
PolicyRuleEntry = {
rule_id: uint .size 2, ; 규칙 식별자 (기존 v0.5)
rule_type: PolicyRuleType, ; 규칙 유형 (기존 v0.5)
parameters: bstr, ; 규칙 파라미터 (기존 v0.5)
enabled: bool, ; 활성/비활성 (기존 v0.5)
reg_tags: RegulationTagBitmap, ; [신규] 이 규칙이 충족하는 규제 태그
}
PolicyRuleType = &(
rule-amount-limit: 1, ; 금액 한도
rule-time-window: 2, ; 시간 제한
rule-quorum: 3, ; 쿼럼 요건
rule-cold-ratio: 4, ; 콜드 보관 비율
rule-whitelist: 5, ; 화이트리스트 주소
rule-audit-enforce: 6, ; 감사 강제 (Phase 30)
rule-role-restrict: 7, ; 역할 기반 제한
rule-velocity: 8, ; 거래 속도 제한
rule-retention: 9, ; 보존 기간
rule-jurisdiction: 10, ; 관할 특화 규칙
)
; 서명 증적에 포함되는 규제 태그 정보
SignatureRegTags = {
applied_rules: [* uint .size 2], ; 적용된 규칙 ID 목록
combined_tags: RegulationTagBitmap, ; 적용 규칙들의 reg_tags OR 결합
active_jurisdictions: bstr .size 2, ; 활성 관할 플래그 (SEAuditDigest 연동)
}
2.2. 비트 할당표 (64-bit)¶
Phase 29에서 식별된 Core 10개 + Delta 18개 = 총 28개 규제 조항을 64-bit 비트맵에 할당한다.
Core 요건 (비트 0~9)¶
| 비트 | 조항 ID | 요건 명칭 | 관련 규제 |
|---|---|---|---|
| 0 | CORE-01 | 고객 자산 분리 보관 | REG-KR-01, REG-EU-02, REG-US-01, REG-JP-01, REG-SG-01 |
| 1 | CORE-02 | 콜드 보관 비율 의무 | REG-KR-02, REG-JP-01, REG-SG-01 |
| 2 | CORE-03 | 감사 로그 장기 보존 | REG-KR-08, REG-EU-03, REG-JP-02, REG-SG-02 |
| 3 | CORE-04 | 변조 불가 감사 로그 | REG-KR-14, CCSS Aspect 10, SOC 2 |
| 4 | CORE-05 | 접근 통제 (RBAC + MFA) | REG-KR-11, CCSS Aspect 6, SOC 2 |
| 5 | CORE-06 | IT 리스크 관리 체계 | REG-KR-06, REG-EU-01, REG-EU-05 |
| 6 | CORE-07 | AML/의심거래 보고 | REG-KR-03, REG-KR-07, REG-SG-02 |
| 7 | CORE-08 | 백업 및 복구 절차 | REG-EU-06, CCSS Aspect 3, SOC 2 |
| 8 | CORE-09 | 정책 변경 이력 관리 | REG-EU-01, SOC 2 CC7.2, CCSS |
| 9 | CORE-10 | 외부 감사 대응 보고서 | REG-EU-03, REG-US-04, CCSS Aspect 7 |
한국 Delta (비트 10~15)¶
| 비트 | 조항 ID | 요건 명칭 | 관련 규제 |
|---|---|---|---|
| 10 | DELTA-KR-01 | 콜드 보관 비율 80% | REG-KR-02 |
| 11 | DELTA-KR-02 | ISMS-P 의무 인증 | REG-KR-05 |
| 12 | DELTA-KR-03 | 클라우드 제한 (국내 리전) | REG-KR-10 |
| 13 | DELTA-KR-04 | 접근 기록 6개월 보관 | REG-KR-15 |
| 14 | DELTA-KR-05 | 금감원 현장 검사 대응 | REG-KR-06 |
| 15 | DELTA-KR-06 | 보존 기간 5년 | REG-KR-08 |
EU Delta (비트 16~21)¶
| 비트 | 조항 ID | 요건 명칭 | 관련 규제 |
|---|---|---|---|
| 16 | DELTA-EU-01 | MiCA CASP 인가 지원 | REG-EU-01, REG-EU-04 |
| 17 | DELTA-EU-02 | DORA ICT 제3자 리스크 등록부 | REG-EU-07 |
| 18 | DELTA-EU-03 | GDPR 삭제권 관리 | REG-EU-08 |
| 19 | DELTA-EU-04 | ESMA JSON 보고 포맷 | REG-EU-03 |
| 20 | DELTA-EU-05 | 국외 데이터 이전 제한 | REG-EU-10 |
| 21 | DELTA-EU-06 | 보존 기간 5년 (MiCA) | REG-EU-03 |
일본 Delta (비트 22~24)¶
| 비트 | 조항 ID | 요건 명칭 | 관련 규제 |
|---|---|---|---|
| 22 | DELTA-JP-01 | 콜드 보관 비율 95% | REG-JP-01 |
| 23 | DELTA-JP-02 | 보존 기간 10년 | REG-JP-02 |
| 24 | DELTA-JP-03 | JFSA 시스템 감사 가이드라인 | REG-JP-04 |
싱가포르 Delta (비트 25~27)¶
| 비트 | 조항 ID | 요건 명칭 | 관련 규제 |
|---|---|---|---|
| 25 | DELTA-SG-01 | 콜드 보관 비율 90% | REG-SG-01 |
| 26 | DELTA-SG-02 | MAS TRM 실시간 관제 | REG-SG-03 |
| 27 | DELTA-SG-03 | MAS PSN02 AML/CFT | REG-SG-02 |
미국 Delta (비트 28~30, Draft 예약)¶
| 비트 | 조항 ID | 요건 명칭 | 상태 |
|---|---|---|---|
| 28 | DELTA-US-01 | GENIUS Act 커스터디 표준 | Draft 예약 |
| 29 | DELTA-US-02 | GENIUS Act 감사 요건 | Draft 예약 |
| 30 | DELTA-US-03 | NY BitLicense 사이버보안 보고 | Draft 예약 |
확장 예약 (비트 31~63)¶
| 비트 범위 | 용도 | 할당 시점 |
|---|---|---|
| 31~39 | 추가 국가 Delta (v0.7+) | 신규 관할 진출 시 |
| 40~55 | 업계 표준/인증 매핑 (CCSS, SOC 2, ISO 27001) | Phase 32+ |
| 56~62 | 커스텀 규제 태그 (고객 정의) | 엔터프라이즈 커스터마이징 시 |
| 63 | 오버플로우 플래그 (확장 비트맵 존재 표시) | 64비트 초과 시 |
2.3. 비트맵 바이트 레이아웃¶
Byte 0: [CORE-01|CORE-02|CORE-03|CORE-04|CORE-05|CORE-06|CORE-07|CORE-08]
bit 0 bit 1 bit 2 bit 3 bit 4 bit 5 bit 6 bit 7
Byte 1: [CORE-09|CORE-10|DKR-01 |DKR-02 |DKR-03 |DKR-04 |DKR-05 |DKR-06 ]
bit 8 bit 9 bit 10 bit 11 bit 12 bit 13 bit 14 bit 15
Byte 2: [DEU-01 |DEU-02 |DEU-03 |DEU-04 |DEU-05 |DEU-06 |DJP-01 |DJP-02 ]
bit 16 bit 17 bit 18 bit 19 bit 20 bit 21 bit 22 bit 23
Byte 3: [DJP-03 |DSG-01 |DSG-02 |DSG-03 |DUS-01 |DUS-02 |DUS-03 |RSVD ]
bit 24 bit 25 bit 26 bit 27 bit 28 bit 29 bit 30 bit 31
Bytes 4~7: [RSVD * 32 bits] -- 향후 확장 예약
3. SE 불변 규칙-규제 조항 매핑 테이블¶
3.1. 기존 v0.5 SE 정책 규칙에 reg_tags 추가¶
기존 v0.5에서 정의된 SE 정책 규칙 테이블(~512B)의 각 규칙에 reg_tags 필드(8B)를 추가한다. 이를 통해 SE가 서명 시 적용된 규칙의 규제 근거를 증적에 포함할 수 있다.
| rule_id | 규칙 명칭 | rule_type | reg_tags (hex) | 매핑 조항 |
|---|---|---|---|---|
| 0x0001 | 콜드 보관 비율 검증 | cold-ratio | 0xE000_0000_0000_0000 |
CORE-01 + CORE-02 + CORE-03 |
| 0x0002 | 단건 금액 한도 | amount-limit | 0x8000_0000_0000_0000 |
CORE-01 (분리 보관 범위 내 한도) |
| 0x0003 | 일일 누적 한도 | velocity | 0x8400_0000_0000_0000 |
CORE-01 + CORE-06 |
| 0x0004 | 쿼럼 N-of-M 서명 | quorum | 0x9800_0000_0000_0000 |
CORE-01 + CORE-05 + CORE-06 |
| 0x0005 | 화이트리스트 주소 제한 | whitelist | 0x8400_0000_0000_0000 |
CORE-01 + CORE-06 |
| 0x0006 | 감사 강제 (로그 실패 시 서명 거부) | audit-enforce | 0xF000_0000_0000_0000 |
CORE-01 + CORE-02 + CORE-03 + CORE-04 |
| 0x0007 | 역할 기반 접근 제한 | role-restrict | 0x8800_0000_0000_0000 |
CORE-01 + CORE-05 |
| 0x0008 | 시간 윈도우 제한 (업무 시간) | time-window | 0x8400_0000_0000_0000 |
CORE-01 + CORE-06 |
| 0x0009 | 정책 버전 단조 증가 강제 | jurisdiction | 0x8080_0000_0000_0000 |
CORE-01 + CORE-09 |
| 0x000A | KR: 80% 콜드 비율 | cold-ratio | 0xE004_0000_0000_0000 |
CORE-01~03 + DELTA-KR-01 |
| 0x000B | KR: 접근 기록 6개월 보관 | retention | 0xB001_0000_0000_0000 |
CORE-01 + CORE-03 + CORE-04 + DELTA-KR-04 |
| 0x000C | KR: 5년 보존 강제 | retention | 0xA000_8000_0000_0000 |
CORE-01 + CORE-03 + DELTA-KR-06 |
| 0x000D | EU: 5년 보존 강제 (MiCA) | retention | 0xA000_0200_0000_0000 |
CORE-01 + CORE-03 + DELTA-EU-06 |
| 0x000E | JP: 95% 콜드 비율 | cold-ratio | 0xE000_0100_0000_0000 |
CORE-01~03 + DELTA-JP-01 |
| 0x000F | JP: 10년 보존 강제 | retention | 0xA000_0080_0000_0000 |
CORE-01 + CORE-03 + DELTA-JP-02 |
3.2. reg_tags 필드 운영 규칙¶
규칙 1: OR 결합 원칙
서명 시 적용되는 모든 규칙의 reg_tags를 비트 단위 OR 연산으로 결합하여 combined_tags를 생성한다.
combined_tags = rule_0x0001.reg_tags | rule_0x0004.reg_tags | rule_0x000A.reg_tags | ...
이 combined_tags가 서명 증적(AuditRecord.payload)에 포함되어, 해당 서명이 어떤 규제 조항을 충족했는지 증명한다.
규칙 2: 최소 Core 보장 모든 배포에서 CORE-01~10 비트(비트 0~9)는 최소 1개 이상 활성이어야 한다. 모든 Core 비트가 0인 상태는 허용되지 않는다.
규칙 3: Delta 배타성
동일 카테고리의 Delta 규칙은 하나만 활성화 가능하다. 예: DELTA-KR-01(80%)과 DELTA-JP-01(95%)가 동시 활성화되면, 더 엄격한 95%가 적용되고 combined_tags에는 두 비트 모두 설정된다.
3.3. 서명 증적 흐름¶
1. 서명 요청 수신
2. SE가 현재 활성 규칙 목록 순회
3. 각 규칙의 조건 평가 (금액, 쿼럼 등)
4. 적용된 규칙의 reg_tags를 OR 결합 -> combined_tags 생성
5. SignatureRegTags 구조 조립:
- applied_rules: [0x0001, 0x0004, 0x000A, ...]
- combined_tags: 0xF804_0000_0000_0000 (예시)
- active_jurisdictions: SEAuditDigest.reserved[0:2]에서 복사
6. AuditRecord.payload에 SignatureRegTags 포함
7. AuditSyncPayload 통해 Zone 1으로 동기화
4. SEAuditDigest reserved(3B) 활용 설계¶
4.1. reserved(3B) 재할당¶
Phase 30에서 예약된 reserved(3B) 필드를 Phase 31에서 다음과 같이 할당한다:
SEAuditDigest reserved field (3 bytes):
Offset Size Field Description
------ ---- ---------------------- ------------------------------------------
0x7D 2 active_jurisdictions 활성 관할 플래그 (16 bits)
0x7F 1 reg_tag_version 규제 태그 스키마 버전
------ ---- ---------------------- ------------------------------------------
Total: 3 bytes
4.2. active_jurisdictions (2 bytes)¶
어떤 관할의 규제 프로파일이 현재 SE에 활성화되어 있는지를 나타내는 플래그이다.
| 비트 | 관할 | 약칭 |
|---|---|---|
| 0 | Core (공통) | CORE |
| 1 | 한국 | KR |
| 2 | EU | EU |
| 3 | 일본 | JP |
| 4 | 싱가포르 | SG |
| 5 | 미국 | US (예약) |
| 6~15 | 향후 확장 예약 | - |
예시:
- 한국 전용 배포: active_jurisdictions = 0x0003 (Core + KR)
- EU+일본 멀티 관할: active_jurisdictions = 0x000D (Core + EU + JP)
- 글로벌 전체: active_jurisdictions = 0x001F (Core + KR + EU + JP + SG)
4.3. reg_tag_version (1 byte)¶
규제 태그 비트맵 스키마의 버전을 나타낸다.
- 초기값:
0x01(Version 1, v0.6에서 정의한 28개 조항 + 예약) - 갱신 조건: 비트맵 할당표가 변경될 때 (신규 조항 추가, 기존 조항 재배치)
- 호환성: 오프라인 앱은
reg_tag_version을 읽어 비트맵 해석 방법을 결정
4.4. SEAuditDigest v0.6.1 업데이트¶
SEAuditDigest (v0.6.1 해석):
Offset Size Field Description
------ ---- ------------------ ------------------------------------------
0x00 1 version 스키마 버전 (0x01 유지)
0x01 4 sign_counter 서명 카운터 (big-endian uint32)
0x05 32 latest_log_hash 마지막 동기화 로그 배치 해시
0x25 32 latest_sign_hash 마지막 서명 트랜잭션 해시
0x45 32 policy_hash 현재 정책 해시
0x65 4 timestamp 마지막 업데이트 시간
0x69 20 digest_sig ECDSA P-256 truncated 서명
0x7D 2 active_jurisdictions [Phase 31] 활성 관할 플래그
0x7F 1 reg_tag_version [Phase 31] 규제 태그 스키마 버전
------ ---- ------------------ ------------------------------------------
Total: 128 bytes (변경 없음)
호환성 보장: 128B 총 크기는 변경 없음. version 필드는 0x01을 유지하되, reserved 3B의 해석이 Phase 31부터 의미를 가진다. Phase 30 이전의 소프트웨어는 이 3B를 무시하므로 하위 호환성 유지.
5. SE NVM 레이아웃 갱신¶
5.1. v0.6.1 NVM 메모리 예산¶
SE NVM 메모리 레이아웃 (v0.6.1 기준)
총 NVM: 16,384 bytes (16 KB)
기존 사용 (v0.5):
키 저장소 (마스터 키, 유도 키 등): ~2,048 bytes
정책 규칙 테이블: ~512 bytes
RBAC 역할 매핑: ~256 bytes
MuSig2 세션 데이터: ~384 bytes
인증서/메타데이터: ~512 bytes
─────────────────────────────────────────────
v0.5 합계: ~3,712 bytes (~3.7 KB)
v0.6 추가 (Phase 30):
SEAuditDigest: 128 bytes
sign_counter NVM 미러링: 4 bytes
audit_key 슬롯 인덱스: 4 bytes
─────────────────────────────────────────────
v0.6 추가 합계: 136 bytes
v0.6.1 추가 (Phase 31):
RegulationTagBitmap (글로벌): 8 bytes (*)
규칙별 reg_tags 확장 (~15규칙 x 8B): ~120 bytes (**)
active_jurisdictions + reg_tag_version: SEAuditDigest reserved 활용 (0B 추가)
─────────────────────────────────────────────
v0.6.1 추가 합계: ~128 bytes
v0.6.1 총 사용: ~3,976 bytes (~3.88 KB)
여유 공간: ~12,408 bytes (~12.12 KB)
(*) SE에 저장되는 현재 활성 규제 태그의 결합 비트맵
(**) 기존 정책 규칙 테이블 ~512B가 ~632B로 확장
(규칙 15개 기준, 기존 entry ~34B → ~42B, +8B/entry)
5.2. NVM 레이아웃 변경 요약¶
| 항목 | v0.5 | v0.6 | v0.6.1 | 증분 |
|---|---|---|---|---|
| 키 저장소 | ~2,048B | ~2,048B | ~2,048B | 0 |
| 정책 규칙 테이블 | ~512B | ~512B | ~632B | +120B |
| RBAC 역할 매핑 | ~256B | ~256B | ~256B | 0 |
| MuSig2 세션 데이터 | ~384B | ~384B | ~384B | 0 |
| 인증서/메타데이터 | ~512B | ~512B | ~512B | 0 |
| SEAuditDigest | 0 | 128B | 128B | 0 |
| sign_counter 미러링 | 0 | 4B | 4B | 0 |
| audit_key 슬롯 | 0 | 4B | 4B | 0 |
| RegulationTagBitmap | 0 | 0 | 8B | +8B |
| 합계 | ~3,712B | ~3,848B | ~3,976B | +128B |
| 사용률 | 22.7% | 23.5% | 24.3% | - |
| 여유 | ~12.3KB | ~12.2KB | ~12.1KB | - |
16KB NVM 대비 24.3% 사용으로, 향후 Phase 31 Plan 02 및 Phase 32+ 확장에 충분한 여유를 확보하고 있다.
6. PolicyChangePayload 규제 태그 연동¶
6.1. 정책 변경 시 비트맵 기록¶
Phase 30에서 정의된 PolicyChangePayload에 규제 태그의 before/after 상태를 추가한다.
; PolicyChangePayload 확장 (Phase 31)
PolicyChangePayload = {
change_type: PolicyChangeType,
policy_version: uint .size 4,
prev_policy_hash: bstr .size 32,
new_policy_hash: bstr .size 32,
changed_rules: [* RuleChange],
; [Phase 31 추가]
reg_tags_before: RegulationTagBitmap, ; 변경 전 결합 비트맵
reg_tags_after: RegulationTagBitmap, ; 변경 후 결합 비트맵
jurisdictions_before: bstr .size 2, ; 변경 전 활성 관할
jurisdictions_after: bstr .size 2, ; 변경 후 활성 관할
}
RuleChange = {
rule_id: uint .size 2,
action: &(added: 1, modified: 2, removed: 3),
? old_tags: RegulationTagBitmap, ; 변경 전 규제 태그
? new_tags: RegulationTagBitmap, ; 변경 후 규제 태그
}
6.2. 감사 추적 활용¶
정책 변경의 규제 영향을 즉시 파악할 수 있다:
| 시나리오 | 비트맵 변화 | 의미 |
|---|---|---|
| 한국 프로파일 활성화 | reg_tags_before=0xFF80... → reg_tags_after=0xFFFC... |
KR Delta 6개 비트 활성화 |
| EU 삭제권 조항 추가 | 비트 18 OFF → ON | GDPR 삭제권 관리 활성화 |
| 일본 10년 보존 비활성 | 비트 23 ON → OFF | 일본 프로파일 해제, 보존 기간 변경 |
| 규칙 제거 | old_tags 존재, new_tags 없음 |
해당 규제 충족이 더 이상 강제되지 않음 |
7. 설계 제약 및 고려사항¶
7.1. 비트맵 크기 결정 근거¶
| 대안 | 크기 | 커버리지 | 채택 여부 |
|---|---|---|---|
| 4 bytes (32 bits) | 4B | 28개 조항 + 4 예약 | 미채택: 확장 여유 부족 |
| 8 bytes (64 bits) | 8B | 28개 조항 + 36 예약 | 채택: 확장 여유 충분 |
| 16 bytes (128 bits) | 16B | 128개 조항 | 미채택: SE NVM 낭비 |
결정 근거: v0.6 28개 조항 + v0.7~v1.0 예상 확장(~15개) + 커스텀 태그(~10개) = ~53개로, 64비트가 최적.
7.2. 성능 영향¶
| 작업 | 추가 시간 | 근거 |
|---|---|---|
| 규칙 순회 시 reg_tags 읽기 | ~0.1ms | 8B 메모리 읽기, 무시 가능 |
| OR 결합 (15규칙 기준) | ~0.05ms | 8B OR 연산 15회 |
| SignatureRegTags 조립 | ~0.5ms | 규칙 목록 + 비트맵 직렬화 |
| 총 서명 시간 영향 | < 1ms | 기존 ~150ms 대비 0.7% 미만 |
서명 수행 시간에 미치는 영향은 무시 가능 수준이다.
7.3. 하위 호환성¶
- Phase 30 소프트웨어:
reg_tags필드가 없는 규칙 테이블을 사용. Phase 31 규칙 테이블과 바이너리 비호환이므로, 펌웨어 업데이트 필수 - 오프라인 앱:
reg_tag_version필드를 확인하여 비트맵 해석 가능 여부 판단. 알 수 없는 버전은 비트맵 해석을 건너뛰고 raw 데이터만 전달 - 대시보드: 비트맵 해석 로직을 서버 측에서 업데이트. 미인식 비트는 "Unknown regulation" 태그로 표시
Phase: 31-hardware-policy-engine, Plan: 01 Version: 1.0 SE NVM 기준: v0.6.1 (~3.88 KB / 16 KB, 24.3% 사용) 규제 태그: Core 10 + Delta 18 = 28개 조항, 64-bit 비트맵
관련 문서¶
- 규제 관할별 사전 구성 정책 프로파일 설계 -- 펌웨어 요구사항
- PolicyUpdateBundle UR 타입 및 에어갭 정책 동기화 프로토콜 -- 펌웨어 요구사항
- SE 정책 버전 관리 및 정책 변경 이력 해시 체인 설계 -- 펌웨어 요구사항