HSM·SGX·Apple Secure Enclave — 개념 정리와 Fireblocks 적용 방식

본 문서는 디지털 자산 커스터디 인프라에서 사용되는 세 가지 신뢰 실행 환경(TEE) — HSM (Hardware Security Module), Intel SGX (Software Guard Extensions) Enclave, Apple Secure Enclave — 의 개념, 키 생성·보관 방식, 알려진 위협, 그리고 Fireblocks가 이들을 어떻게 활용해 MPC-CMP 키 샤드를 보호하는지 정리합니다. Key Link 옵션은 본 문서 범위에서 제외하며, 모든 Fireblocks 고객이 디폴트로 받게 되는 보안 계층에 초점을 맞춥니다.

1. HSM (Hardware Security Module)

키를 만들고, 보관하고, 서명하는 전용 하드웨어 보안 칩/장비. 일반 서버나 OS와 분리된 별도의 신뢰 경계(trust boundary)를 가집니다.

1.1 핵심 특성

1.2 키 생성·보관 방식

HSM 내부에는 TRNG(True Random Number Generator) 가 내장되어 있어 (대부분 노이즈 다이오드·열잡음 기반의 물리 엔트로피원) 키 재료 자체가 칩 안에서 만들어집니다.

[ HSM 내부 ]
   ├─ TRNG (FIPS 인증 난수 생성기)
   ├─ 키 저장소 (보호된 메모리, 탬퍼 감지 시 즉시 wipe)
   ├─ 암호 연산 엔진 (서명·암복호화 가속기)
   └─ 외부 인터페이스 (PCIe / 네트워크) ← 키는 안 나가고 결과만 나감

키가 HSM 밖으로 추출되는 명령어 자체가 존재하지 않습니다. 백업이 필요하면 KEK(Key Encryption Key)로 감싼 암호문 형태로만 export 가능하고, KEK도 다른 HSM 안에 있어야 풀 수 있습니다.

1.3 쓰이는 자리

• 은행 결제망 (PIN/PCI-PIN, EMV)
• CA(인증기관)의 루트키 관리
• CBDC, 정부 PKI
• FIPS 140-2 Level 3 이상 인증을 명문으로 요구하는 금융·국방·의료 시스템
• 디지털 자산 기관 커스터디(예: Fireblocks Key Link, BitGo Custody Standard)

1.4 한국 규제 관점

이용자보호법·특금법·KISA 가이드 어디에도 HSM 도입 의무 조항은 없습니다. "안전한 키 관리 시스템 사용" 정도 권고이므로 일반 VASP·커스터디는 HSM 없이도 규제를 충족할 수 있습니다. HSM은 한국에서는 자율 보안 정책 또는 해외 모회사 규제 준수 차원에서 선택되는 장치입니다.

2. Intel SGX (Software Guard Extensions) Enclave

Intel CPU 내부에 만드는 소프트웨어 격리 영역(Enclave). 별도 하드웨어 구매 없이 일반 Xeon 등 SGX 지원 CPU에서 실행됩니다.

2.1 핵심 특성

2.2 키 생성 메커니즘 — "CPU 다이 내부에서 끝남"

SGX의 모든 키는 CPU 다이(die) 내부에서 생성·파생되며, 평문 상태로 칩 밖으로 절대 나오지 않습니다. RAM·디스크·OS는 키의 평문을 한 번도 보지 못합니다.

2.2.1 두 가지 키 계층

(1) 루트 키 (Hardware Root) — CPU 제조 시 칩에 굳어짐(fused)

CPU 제조 단계에서 e-fuse(전기적으로 한 번만 쓸 수 있는 회로)에 새겨지는 256비트 비밀값들:

이 두 값은 CPU 내부에서만 읽을 수 있는 특별 회로에 저장됩니다. 운영체제·하이퍼바이저·심지어 BIOS도 직접 읽지 못하며, EGETKEY 명령어를 통해 간접적으로 파생된 키만 외부에 노출됩니다.

(2) 애플리케이션 키 — 엔클레이브가 그때그때 파생/생성

엔클레이브가 필요할 때 CPU 명령어로 키를 얻습니다:

[ Enclave 코드 ]
      │
      │  EGETKEY 명령어
      ▼
[ CPU 키 파생 회로 ]  ← Root Sealing Key + 엔클레이브 측정값(MRENCLAVE) + 정책
      │
      ▼
[ 엔클레이브 안의 메모리 ]  ← 여기에만 평문이 존재

같은 CPU의 다른 엔클레이브는 같은 키를 얻지 못합니다 — MRENCLAVE(코드 해시)가 달라서 다른 키가 파생되기 때문입니다. 이 성질이 SGX의 격리 보장의 근간입니다.

2.2.2 실제 키 생성 흐름 — Fireblocks MPC 샤드 예시

엔클레이브 코드가 새 비밀(예: MPC 샤드)을 만들고 디스크에 보관하는 과정:

1. 엔클레이브 진입 (EENTER)
       ↓
2. 엔클레이브 안에서 RDRAND/RDSEED 실행
   ├─ RDRAND  : CPU 내장 하드웨어 RNG (NIST SP 800-90A/B/C 인증)
   └─ RDSEED  : RDRAND의 시드, 진정 난수
       ↓
3. 난수로 MPC 샤드 키 생성  ← 여기서 키가 "태어남"
       ↓
4. EGETKEY로 Sealing Key 받음 (Root Sealing Key + MRENCLAVE에서 파생)
       ↓
5. AES-GCM 으로 샤드를 Sealing Key로 암호화
       ↓
6. 암호문만 OS·디스크에 저장 (.sealed 파일)
       ↓
7. 엔클레이브 종료 (EEXIT) — 평문 샤드는 메모리에서 소거

핵심 포인트:

• 3번에서 키가 "생성"되는 위치는 EPC(Enclave Page Cache) — CPU가 메모리 컨트롤러 단에서 자동 암호화하는 RAM 영역
• 4번의 Sealing Key는 RAM에도 안 들어가고 CPU 레지스터에서만 사용
• OS가 메모리 덤프해도 EPC 영역은 MEE(Memory Encryption Engine) 가 암호화한 상태로만 보임
• 6번 이후 디스크에 저장된 .sealed 파일은 같은 CPU의 같은 엔클레이브 가 아니면 복호화할 수 없음 (다른 PC로 옮기면 풀 수 없음 = "CPU에 묶인다"는 의미)

2.2.3 핵심 구성요소 / 명령어

2.3 쓰이는 자리

• 클라우드 비밀 키 보관
• Confidential Computing (기밀 데이터 처리)
• MPC 노드의 샤드 보관소
• 디지털 자산 커스터디 SaaS의 신뢰 실행 환경(TEE)
• DRM, 라이선스 관리

2.4 알려진 SGX 위협 — Zero-day와 부채널 공격

2.4.1 Zero-day란?

제로데이(Zero-day) = 벤더가 패치를 만들 시간이 0일이었던 보안 취약점. 즉, 공격자가 먼저 알고 있고 아직 패치가 없는 취약점을 말합니다.

세 가지 표현으로 자주 쓰입니다:

왜 위험한가:

• 백신·EDR·시그니처 기반 방어로는 잡을 수 없음 (정의가 아직 없음)
• 패치 배포 전까지 모든 사용자가 무방비
• 다크웹·국가급 행위자(NSO Group 같은 곳)가 수억 원~수십억 원에 거래

2.4.2 SGX 부채널 공격의 본질

키가 칩 안에서 생성·보관되는 건 맞는데, CPU 내부 동작 패턴(전력·캐시·타이밍) 을 외부에서 측정해 키를 역산하는 공격이 가능합니다. SGX는 물리 칩 자체를 뜯는 공격은 막지 못하고, 소프트웨어 격리만 강제하기 때문입니다.

2.4.3 대표 SGX zero-day 사례

→ 이런 이유로 가이드에서 "SGX는 강하지만 zero-day가 주기적으로 보고됨", "FIPS 140-2 Level 3 HSM은 물리 탐침까지 방어" 라고 표현합니다. 패치는 마이크로코드 업데이트로 이루어지지만, 발견 → 패치 사이의 윈도우가 항상 존재합니다.

2.4.4 그래도 SGX가 안전한 이유 — MPC와의 결합

SGX 단독에 의존하면 위험할 수 있지만, Fireblocks는 SGX를 MPC와 결합해 사용합니다:

• 한 샤드의 SGX가 뚫려도 다른 샤드 없이는 서명을 만들 수 없음
• Guard Co-Signer로 여러 SGX 노드에 m-of-n 쿼럼을 적용하면 단일 zero-day의 영향이 더 줄어듦
• Cosigner 자체도 마이크로코드 패치를 빠르게 받음

3. Apple Secure Enclave

iPhone·iPad·Apple Watch·Mac에 내장된 별도 보안 코프로세서. SGX와 같은 계열의 TEE이지만 Apple이 자체 설계한 ARM 기반 칩입니다.

3.1 적용 기기

A7 SoC(2013) 이후 Apple이 만든 거의 모든 디바이스에 들어 있습니다. 별도 옵션이 아니라 칩 자체에 내장되어 있어 사용자가 활성화할 필요도 없습니다.

3.2 실제로 처리하고 있는 것

당신의 iPhone에서 Secure Enclave가 이미 다음을 처리하고 있습니다:

• Face ID / Touch ID — 생체 정보의 수학적 표현(템플릿)을 SE 안에서만 보관·매칭. iOS·앱조차 원본을 못 봄
• Apple Pay — 결제 토큰·디바이스 계정 번호(DAN) 격리, 결제 시 Touch/Face ID 검증
• iMessage·FaceTime 종단간 암호화 키
• iCloud Keychain 동기화 키
• Find My 위치 인증 키
• Photos의 사람 인식·Siri 개인화 등 디바이스 내 ML 키
• Wallet 의 자동차 키·집 키·여권·디지털 ID
• Passkey (FIDO2 패스키)
• App Attest (앱이 정상 Apple 기기에서 실행 중임을 증명)
• 데이터 보호 (Data Protection) — iOS 파일 시스템 암호화 키

3.3 일반 앱·OS와의 분리

┌──────────────────────────────────────────────────┐
│  iOS / 사용자 앱 / 사용자                          │  ← Secure Enclave 안을 절대 못 봄
└─────────────────┬────────────────────────────────┘
                  │
┌─────────────────▼────────────────────────────────┐
│  Application Processor (A 시리즈/M 시리즈 메인)    │
└─────────────────┬────────────────────────────────┘
                  │  암호화된 메일박스만 통과
                  │  (Mailbox 메커니즘)
┌─────────────────▼────────────────────────────────┐
│  Secure Enclave Processor                        │
│  ├─ 자체 ARM 기반 CPU (메인 CPU와 물리 분리)       │
│  ├─ 자체 암호화된 RAM (메인 RAM과 분리된 SRAM)     │
│  ├─ 자체 비휘발성 저장소 (Effaceable Storage)      │
│  ├─ AES 가속기 + TRNG                            │
│  └─ Public Key Accelerator (PKA)                 │
└──────────────────────────────────────────────────┘

탈옥(jailbreak)을 해서 iOS 루트 권한을 얻어도 Secure Enclave 안의 키는 추출되지 않도록 설계되어 있습니다.

3.4 SGX와의 차이점

핵심 차이: SGX는 공유 CPU의 격리 영역, Secure Enclave는 물리적으로 분리된 별도 칩. 그래서 부채널 공격면이 훨씬 좁고, 동시에 외부 개발자가 자유 코드를 실행할 수 없어 공격 표면 자체가 작습니다.

3.5 Fireblocks와의 연결

Fireblocks 모바일 Cosigner / 에어갭 iOS Cosigner 가 활용하는 것이 바로 이 Apple Secure Enclave입니다:

• MPC 샤드를 SE 안에 보관
• QR 코드로 받은 트랜잭션을 SE 안에서 서명
• iOS 앱 코드도 SE 안의 평문 샤드를 직접 만지지 못함
• 기기를 분실해도 PIN/Face ID 없이는 서명 불가

💡 이미 당신 iPhone에서 Face ID가 되고 있다면, Secure Enclave가 활발하게 일하고 있는 중입니다. Fireblocks 모바일 Cosigner는 그 위에 한 층 더 얹는 구조예요.

4. 세 가지 TEE 비교 — HSM vs SGX vs Apple Secure Enclave

한 줄 요약:

• HSM = "비싸고 강한 하드웨어 금고" — FIPS 의무가 있을 때
• SGX = "값싸고 클라우드 네이티브한 소프트웨어 금고" — 클라우드 MPC 노드
• Secure Enclave = "사용자 디바이스에 박혀 있는 무료 금고" — 모바일 서명·인증

세 가지 모두 키를 격리하지만 신뢰 경계의 두께와 공격면이 다릅니다.

5. MPC와의 관계 — "대체재가 아니라 계층"

MPC(Multi-Party Computation)와 HSM/SGX/Secure Enclave는 동일 계층의 대체재가 아니라, 목적이 다른 두 보호 계층 입니다.

MPC                      = 키를 "여러 샤드"로 분산 → 단일 장애점(SPOF) 제거
HSM/SGX/Secure Enclave   = 각 샤드를 "추출 불가 환경"에 보관 → 메모리 덤프·멀웨어 차단

Fireblocks는 MPC-CMP 샤드를 반드시 SGX(서버) / Secure Enclave(모바일) / HSM(Key Link 옵션) 안에서만 다루도록 설계해 두 계층을 결합합니다.

6. Fireblocks가 SGX와 HSM을 제공하는 방식

Fireblocks는 단일 개인키가 아니라 여러 MPC 샤드를 다루므로, "각 샤드를 어디에 저장하고 어디서 서명할지"가 보안의 핵심입니다.

6.1 SGX·Secure Enclave — 모든 Fireblocks 고객의 디폴트

별도 추가 비용·하드웨어 없이 모든 Fireblocks 워크스페이스에 자동 적용되는 기본 보안 계층 입니다.

핵심 원칙 — 샤드는 절대 평문으로 디스크나 메모리에 노출되지 않습니다. MPC 서명 라운드 자체도 TEE 안에서만 이루어지고, 결과 서명만 밖으로 나옵니다.

6.2 Guard Co-Signer — SGX 강화 옵션

여전히 SGX 기반이지만, 여러 노드에 분산해 가용성·쿼럼 정책·공격면 축소 를 추가하는 옵션입니다.

• 4개의 SGX 기반 Co-Signer를 서로 다른 AZ/DC에 배치
• m-of-n 임계값 서명 (예: 3-of-4)
• 한 노드가 SGX zero-day로 뚫려도 단독으로는 서명 불가
• Fireblocks가 운영 (고객은 정책만 설정)

6.3 HSM — 옵션 (BYO 모델)

Fireblocks는 HSM을 호스팅해 주지 않습니다. "고객 소유 HSM을 가져와 통합"하는 BYO(Bring Your Own) 모델로만 제공됩니다.

📌 본 문서는 Key Link를 다루지 않습니다. Key Link 상세는 별도 가이드의 8~9장을 참고하세요.

7. Fireblocks 보안 스택의 전체 그림

[ 고객 자산 ]
     │
     ▼
[ MPC-CMP 샤드 3개 (3-of-3) ]   ← 단일 개인키 자체가 존재하지 않음
     │
     ├── 샤드 1 → Fireblocks Cloud      → SGX Enclave (기본)
     │                                        ↑ EPC + RDRAND + EGETKEY
     │                                        ↑ 마이크로코드 패치로 zero-day 대응
     │
     ├── 샤드 2 → 모바일/Cosigner       → Apple Secure Enclave (기본)
     │                                        ↑ 별도 코프로세서, sepOS만 실행
     │                                        ↑ Face ID/Touch ID로 사용자 인증
     │
     └── 샤드 3 → 고객 API Co-Signer    → SGX (기본) / HSM (Key Link 시 교체)
                                              ↑
                                Guard Co-Signer 추가 시
                                여러 SGX 노드를 m-of-n 분산
                                (여전히 SGX, 하지만 단일 zero-day 영향 축소)

핵심 메시지:

• 모든 Fireblocks 고객은 자동으로 SGX + Secure Enclave 보안을 받고 있음 — 별도 옵션이 아닙니다
• 세 샤드 모두가 서로 다른 신뢰 경계에 분산되어 있어 하나의 zero-day로는 전체가 무너지지 않음
• HSM은 옵션 이며, 그것도 Fireblocks 호스팅이 아닌 고객이 가져오는 BYO 모델
• 일반 VASP·커스터디는 SGX + Secure Enclave 스택만으로 규제·보안 요건을 충족, HSM은 키 주권·FIPS 명시·벤더 독립이 필요한 기관만 추가합니다

8. FAQ

8.1 SGX Enclave는 HSM과 같은 건가요?

같지 않습니다. 둘 다 "샤드 보관소" 역할을 하지만 보호 수준이 다릅니다. SGX는 CPU 기반 소프트웨어 격리로 강력하지만 Foreshadow·ÆPIC Leak 같은 zero-day가 꾸준히 보고됩니다. FIPS 140-2 Level 3 HSM은 전용 하드웨어로 물리 탐침 공격까지 방어 설계되어 있습니다. 규제가 "FIPS 인증 HSM"을 명시하면 SGX만으로는 준수가 어렵습니다.

8.2 SGX는 키를 어디서 생성하나요?

Intel CPU 다이 안의 EPC(Enclave Page Cache) 영역에서 RDRAND/RDSEED 명령어로 생성합니다. 그리고 EGETKEY 명령어로 파생한 Sealing Key로 암호화한 뒤에야 디스크에 내보냅니다. 평문 키는 EPC 안에서만, 그것도 엔클레이브 코드가 실행되는 동안만 존재합니다. Sealed 데이터는 같은 CPU의 같은 엔클레이브 가 아니면 복호화할 수 없습니다.

8.3 MPC와 HSM 중 하나만 고르면 되지 않나요?

아니요. 둘은 대체재가 아니라 계층이 다른 보호장치입니다.

• MPC — 키를 여러 샤드로 분산해 단일 장애점을 없앰
• HSM/SGX/Secure Enclave — 각 샤드를 추출 불가한 격리 환경에 보관

MPC만 있고 샤드가 평범한 서버 메모리에 있으면 덤프·멀웨어로 유출 가능. HSM만 있고 키 1개를 넣으면 HSM 자체가 SPOF. Fireblocks는 MPC 샤드를 SGX(또는 HSM·Secure Enclave) 안에서만 다루게 해서 두 계층을 결합합니다.

8.4 한국 VASP는 HSM이 꼭 필요한가요?

아니요. 이용자보호법·특금법·KISA 어느 조항도 HSM을 명문으로 요구하지 않습니다. MPC + SGX + 에어갭 으로 한국 규제는 충족됩니다. HSM은 키 주권·해외 모회사 정책·FIPS 인증 명시 요구가 있는 기관에서만 추가합니다.

8.5 SGX zero-day가 자주 발견되는데, 그래도 안전한가요?

SGX 단독에 의존하면 위험할 수 있지만, Fireblocks는 SGX를 MPC와 결합해 사용합니다. 한 샤드의 SGX가 뚫려도 다른 샤드 없이는 서명을 만들 수 없습니다. Guard Co-Signer로 여러 SGX 노드에 m-of-n 쿼럼을 적용하면 단일 zero-day의 영향이 더 줄어듭니다. 마이크로코드 업데이트로 발견된 취약점은 빠르게 패치됩니다.

8.6 Zero-day는 정확히 무엇을 말하나요?

벤더가 패치를 만들 시간이 0일이었던 보안 취약점 — 즉, 공격자가 먼저 알고 있고 아직 패치가 없는 상태입니다. 백신·EDR로는 잡을 수 없고 패치 배포 전까지 모든 사용자가 무방비라는 점이 위험합니다. Stuxnet(2010)은 zero-day 4개를 동시에 사용했고, NSO Group 같은 행위자는 한 건당 수억~수십억 원에 거래합니다.

8.7 iPhone에 Apple Secure Enclave가 들어 있나요?

네. iPhone 5s(2013) 이후 모든 iPhone·iPad·Apple Watch·Apple Silicon Mac에 별도 보안 코프로세서로 내장되어 있습니다. Face ID/Touch ID, Apple Pay, iMessage 암호화, Passkey 등이 이미 SE 위에서 동작 중입니다. Fireblocks 모바일 Cosigner는 그 위에 MPC 샤드 한 층을 더 얹는 구조입니다.

8.8 Apple Secure Enclave가 SGX보다 안전한가요?

공격면 측면에서 더 좁습니다. 별도 코프로세서라서 메인 CPU의 캐시·전압·추측 실행 부채널 공격에 노출되지 않고, Apple이 정의한 sepOS만 실행되므로 외부 개발자가 임의 코드를 돌릴 수 없습니다. 다만 FIPS 140-2 인증은 받지 않으며, Apple 디바이스에 종속됩니다 — 클라우드 서버에서는 사용할 수 없어 SGX와 용도가 다릅니다.

8.9 Fireblocks 모바일 앱으로 서명하려면 비밀번호 외에 뭐가 필요한가요?

iOS 기기 자체와 Face ID/Touch ID 입니다. 모바일 Cosigner의 MPC 샤드는 Secure Enclave 안에 있고, 서명 시점에 사용자 생체 인증이 함께 요구됩니다. 기기를 분실해도 생체 인증 없이는 샤드를 깨워서 서명할 수 없습니다.

9. 용어집

10. 참고 자료

• Intel SGX 공식 문서
• Intel SGX Programming Reference (SDM Vol. 3D)
• FIPS 140-2 / 140-3 표준
• Apple Platform Security Guide
• Apple Secure Enclave 상세
• Fireblocks MPC-CMP 백서
• Fireblocks Guard Co-Signer 개요
• 본 저장소의 fireblocks-custodial-cold-wallet-guide.md 8장 — HSM 도입 판단 / 9장 — Key Link 아키텍처

SGX 공격 사례 (학술 논문)

• Foreshadow (USENIX Security 2018) — https://foreshadowattack.eu
• Plundervolt (S&P 2020) — https://plundervolt.com
• ÆPIC Leak (USENIX Security 2022) — https://aepicleak.com
• Downfall / GDS (USENIX Security 2023) — https://downfall.page