안녕하세요 한국디지털에셋 개발자 한황제입니다. 크립토 지갑 및 수탁 시스템을 9년 가까이 설계·운영하면서 가장 자주 받는 질문이 하나 있어요. “MPC, 멀티시그, HSM — 그래서 어느 게 제일 안전해요?”

결론부터 말씀드릴게요. 어느 하나만으로는 전체 위협을 해결할 수 없어요.

MPC는 키를 분산해요. 멀티시그는 서명자 수를 분배하고요. HSM은 키를 밖으로 나가지 못하게 잠그죠. 셋 다 분명히 강력해요. 그런데 셋 다 키를 어떻게 보관·분산할지에 대한 답이에요. 커스터디에서 진짜 무서운 위협은 키가 빠져나가는 게 아니라, HSM 안에 멀쩡히 들어 있는 키가 허가받지 않은 명령에 서명하는 일이거든요. 키는 그대로 있어도 자산은 빠져나가요.

저희가 이 문제를 풀어 온 방식은 두 축이에요. 하나는 온라인 영역과 에어갭 영역을 단방향 QR 코드로만 연결한 것. 다른 하나는 정족수와 권한 분리가 HSM 내부에서 강제되는 쿼럼 빌트인 HSM을 채택하고, 그 위에 KODA의 통합 레이어를 얹어 단일 신뢰 경계를 만든 것이에요. 이 글은 그 통합 아키텍처가 어떤 위협을 어떻게 완화하는지를 컴포넌트와 시퀀스로 풀어 봅니다.

키를 잃는 것보다 무서운 건, 적법해 보이는 잘못된 서명이거든요.

1. 첫 번째 방어선: 온라인 서비스와 Cold Wallet 영역 분리

저희 시스템은 물리적으로 두 영역으로 쪼개져 있어요.

Service Zone은 온라인 커스터디 서비스와 운영자 단말이 있는 영역이에요. 외부 네트워크와 통신하고, 트랜잭션 요청을 받고, 서명 결과를 모아 블록체인 네트워크에 전송하는 역할을 해요. ColdWallet Zone은 외부 네트워크와 차단된 격리 영역입니다. 여기에는 콜드월렛 어플리케이션, 승인자용 하드웨어 보안 인증 장치, 키 관리 미들웨어, 그리고 HSM이 들어 있어요. 오프라인 데이터 검증, 모든 서명 연산은 이 영역 안에서만 일어나죠.

두 영역 사이에는 사전에 약속된 QR 전송 절차 외엔 어떤 네트워크 연결도 없어요.

QR 채널 자체도 평문이 흐르진 않습니다. Service Zone에서는 요청 데이터를 직렬화한 뒤 암호화해요.

QR 페이로드 보호 (개념)
  ├─ Service Zone <-> Cold Zone 공개키 교환
  ├─ 비대칭키 기반 하이브리드 암호화를 위한 대칭키 생성
  └─ 인증된 대칭키 암호화

QR 코드는 누구나 카메라로 찍을 수 있는 매체예요. 그래서 경로 중간에 캡처되더라도 평문이 노출되지 않도록, 요청이 생성된 곳에서 서명 영역까지 전 구간에서 암호화가 유지되게 설계했어요.

두 영역을 물리적으로 갈라 놓고 단방향 QR로만 잇는 것, 그게 첫 번째 방어선이에요.

2. 두 번째 방어선: ColdWallet Zone 내부의 책임 분리와 비동기 승인 워크플로우

ColdWallet Zone은 한 덩어리가 아니에요. 4개의 컴포넌트로 나뉘어져 있고, 각자 책임이 다릅니다.

승인자는 PIV(NIST SP 800-73-4) 표준 기반의 FIPS 인증을 받은 하드웨어 인증 장치를 사용해요. 사용 중인 모델과 운영 모드가 인증 범위에 포함되는 것을 확인하고 도입했어요. 인증 장치의 서명 전용 키는 외부로 추출되지 않도록 설계된 슬롯에 보관되고, 승인자는 서명 요청에 대해 해당 키로 총 두 번 서명합니다.

이 두 서명은 같은 키로 만들지만 의미가 달라요. 타임스탬프 서명은 “이 키의 소유자가 지금 이 순간 직접 참여하고 있다”는 시점 증명이에요. 챌린지 서명은 “이 특정 서명 세션에 동의한다”는 세션 결합 증명이고요. 둘이 합쳐져서 과거 승인이 재사용될 위험을 완화합니다.

인증 장치로 만든 두 서명은 ColdWallet Application → 키 관리 미들웨어 경로로 들어와요. 미들웨어는 요청을 받아 세션을 관리하고, HSM 쿼럼 인증으로 라우팅해요.

키 관리 미들웨어가 책임지는 일
  ① 요청 수신·라우팅
  ② 사용자 인증과 기능별 인가
  ③ 세션 식별자 발급·만료 관리
  ④ 서명 요청 라이프사이클 관리 (대기 → 실행/만료/취소)
  ⑤ HSM 쿼럼 인증 호출 중계 (요청 ↔ 응답)

검증의 본체는 미들웨어가 아니에요. 정족수, 정책, 세션 정합성 — 모두 HSM 내부에서 강제됩니다. 미들웨어는 그 호출을 받아 라우팅하고, 비동기 워크플로를 추적할 뿐이에요.

다만 미들웨어는 단순 프록시에 머물지 않아요. 각 서명 요청을 비동기 워크플로로 따로 추적해서, 서명자들이 동시에 모이지 않아도 되게 해요. 요청 상태에는 다음이 담깁니다.

서명 요청 상태 (개념)
  ├─ 요청 식별자와 만료 시각
  ├─ 승인 진행 상태와 남은 정족수
  ├─ HSM 서명 세션 바인딩 정보
  └─ 감사·사후 검증 정보

이 구조가 지켜 주는 건 다섯 가지예요. 요청이 고유하게 식별되고, 승인과 HSM 세션이 연결되며, 요청이 무기한 유지되지 않고, 재시도가 중복 실행으로 이어지지 않으며, 사후 추적이 가능하다는 것.

요청 만료는 HSM 정책의 유효 시간과 동기화되어 있어요. 무한 대기 요청이 쌓이지 않게 하려는 거예요. 동일 요청의 재등록은 멱등 처리됩니다 — 네트워크 재시도가 중복 요청을 만들지 않아요.

정책 강제의 본체는 HSM 안에 있어요. 미들웨어는 그 앞단에서 요청을 모으고 세션을 관리할 뿐이에요. 그러면 그 안쪽은 어떻게 생겼을까요?

3. 세 번째 방어선: 쿼럼 빌트인 HSM, 그리고 그 위의 통합 레이어

여기가 일반적인 HSM 활용 방식과 KODA 커스터디 코어가 갈라지는 지점입니다.

3-1. 토대 — HSM이 직접 검증하는 정책

기본 PKCS#11 인터페이스 중심의 일반적인 구성에서 HSM의 핵심 보안 명제는 “키는 밖으로 나가지 않는다”예요. 키 보관에는 탁월하죠. 다만 그 키로 무엇에 서명할지 — 몇 명이 동의했는지, 업무적으로 적법한 요청인지 — 의 판단은 호스트 애플리케이션이 담당하는 경우가 많아요. 이 지점이 보안에 취약할 수 있습니다. 호스트가 침해되면, 조직의 결재 의사와 무관한 서명 요청이 정상 요청과 구분되지 않은 채 HSM에 도달할 수 있거든요.

저희가 채택한 HSM은 이 판단을 장비 안으로 가져옵니다. 정족수와 정책 객체를 HSM 내부에 두고, HSM 안에서 t-of-n과 권한 규칙을 다시 계산하는 구조예요. 정책 객체는 4계층 트리로 구성됩니다.

AND/OR 관계가 헷갈리기 쉬운데 이렇게 보면 돼요. 그룹 간엔 AND(한 토큰을 충족하려면 그 토큰 안의 모든 그룹의 정족수를 채워야 함), 토큰 간엔 OR(한 권한 규칙을 충족하려면 그 규칙 안의 어느 한 토큰만 채우면 됨). 토큰은 권한 규칙 차원에서 OR로 묶이는 독립 경로고, 그룹은 토큰 차원에서 AND로 묶이는 필수 단위예요.

서명 요청이 들어오면, HSM은 사용 권한 규칙(Use) 아래 트리를 펼쳐 두고 다음 다섯 항목을 내부에서 다시 검증합니다. 승인자 공개키가 사전에 등록된 것인지, 승인 데이터가 유효한지, 정족수가 충족됐는지, 추가 정책 조건을 만족하는지, 그리고 세션 식별자가 정합한지.

다섯 항목 중 단 하나라도 불충족이면 HSM은 서명을 거부해요. 호스트가 무엇을 요청했든 무관해요. 정책은 HSM 안에서 살아 있어요.

여기까지가 저희가 채택한 HSM이 표준으로 제공하는 보장이에요. 이 위에 저희가 얹은 게 있어요.

3-2. KODA 통합 레이어 1 — 권한 분리 정책 설계

정책 엔진은 HSM이 제공합니다. 그러나 그 정책을 어떻게 설계하는가는 KODA 운영의 영역이에요. 저희가 운영하는 패턴은 세 가지예요.

첫째, 사용/변경 권한 분리. 사용 규칙(Use)에 묶인 그룹과 변경 규칙(Modify)에 묶인 그룹의 구성원을 일부러 다르게 가져갑니다. 일상적으로 서명을 진행하는 사람과, 정책 자체를 갈아끼울 권한이 있는 사람을 분리해 두는 거예요. 정책 변경자가 곧 서명자인 시나리오를 막으려는 거예요.

둘째, 차단/차단 해제 권한 분리. 사고가 났을 때 키를 즉시 차단할 권한과, 차단을 푸는 권한을 별도로 둡니다. 같은 사람이 차단하고 풀면 차단의 의미가 없어지거든요.

셋째, 정상 운영 권한과 비상 복구 권한의 분리. 정상 운영용 승인 토큰과 백업용 승인 토큰은 물리적·논리적으로 분리된 구역에 격리 보관하고, 두 토큰 그룹 간 교차 승인은 HSM 정책에서 차단되도록 구성해요. 한쪽 구역이 침해돼도 다른 쪽의 승인 체계는 독립적으로 유지되죠. 정족수는 자산의 민감도와 운영 위험에 따라 차등 적용하고요.

HSM의 정책 엔진을 사용할 수 있지만, 이런 분리 설계는 HSM이 알아서 해 주지 않아요.

3-3. KODA 통합 레이어 2 — 미들웨어 통합 레이어와 비동기 다중 서명자

HSM 정책을 코드로 관리하는 책임은 KODA의 키 관리 미들웨어가 집니다. 마스터 키를 만들 때 기능별 정책 템플릿을 결합하는 구조를 개념적으로 그리면 이래요. (실제 운영 명령·경로와는 다른 예시입니다.)

마스터 키 생성 (개념)
  ├─ 키 식별자 지정
  └─ 기능별 정책 결합
      ├─ 사용(Use) 권한 정책
      ├─ 변경(Modify) 권한 정책
      ├─ 차단(Block) 권한 정책
      └─ 차단 해제(Unblock) 권한 정책

승인자 등록, 정책 객체 생성, 마스터 키 라이프사이클(차단/해제/회전) 관리가 모두 미들웨어의 관리 인터페이스 뒤에 들어 있어요. 정책이 코드로 표현되니까 권한 분리를 코드 리뷰 단위에서 강제할 수 있어요.

미들웨어가 관리하는 핵심 접근 제어 메타데이터는 세 가지예요. 승인자 등록 정보, 승인자별로 사전 등록된 하드웨어 인증 장치 공개키 화이트리스트, 그리고 키별 승인자 정책 매핑(어느 승인자가 어느 마스터 키의 정책 객체에 속하는지). 사용자가 인증 세션만 얻었다고 해서 키에 접근할 수 있는 게 아니에요. 그 사용자의 하드웨어 인증 장치가 등록된 승인자 장치인지, 그 승인자가 해당 키의 정책에 등록된 자인지를 미들웨어가 매번 검증해요. 화이트리스트 매핑이 깨지면 요청 자체가 HSM에 닿지 않습니다.

이 모든 흐름은 자동으로 감사 로그에 남아요. 정책 객체 변경은 버전 관리 이력으로 추적되고, 서명 요청·승인 데이터·HSM 내부 검증 결과는 미들웨어와 HSM 각각의 audit log로 보존됩니다. 승인자 식별 정보·타임스탬프·세션 식별자가 모두 연계되어 있어서 누가, 언제, 어떤 정책으로, 어떤 서명을 만들었는가의 주요 의사결정과 실행 이력을 사후에 추적할 수 있어요. 가상자산이용자보호법 대응이나 SOC 2, ISO/IEC 27001 같은 외부 감사의 증적으로 활용할 수 있도록 설계한 부분이고, 운영의 부산물로 따라오는 셈이에요.

그 위에 섹션 2에서 보여드린 비동기 추적 모델이 얹혀 있어요. HSM은 한 번에 한 서명 세션의 정족수만 검증하지만, 다중 서명자가 다른 시간·다른 장비에서 비동기로 들어오는 운영 워크플로는 HSM이 알아서 추적해 주지 않거든요. 미들웨어가 요청 상태를 멱등 키로 보존하고, 승인 진행과 HSM 세션 바인딩을 누적하고, 요청 만료를 HSM 정책과 동기화해서 무한 대기 요청을 막아요. 1차 서명자가 등록한 뒤, 2차 서명자가 본인 일정에 맞춰 몇 시간 뒤 대기 목록을 가져가 승인하는 시나리오가 자연스럽게 돌아가요.

다중 서명자가 동시에 모이지 않아도 되는 비동기 모델, 이게 운영 자유도를 만들어요. 그 자유도가 보안과 충돌하지 않는 이유는, 최종 강제가 여전히 HSM 안에서 일어나기 때문이에요.

3-4. KODA 통합 레이어 3 — 2단 인증 (요청·실행 권한의 분리)

서명 한 번을 만들어 내려면 두 개의 인증 경계를 모두 통과해야 합니다. 요청 권한과 실행 권한이 분리되어 있거든요.

[레벨 1] 요청 권한 — 미들웨어 인증·인가
   ├─ 사용자 인증 → 세션 발급                  (사용자 식별)
   ├─ 기능별 최소 권한 인가                    (호출 가능한 기능 제한)
   └─ 승인자 ↔ 하드웨어 인증 장치 화이트리스팅 검증  (실제 권한 체크)
       "이 사용자의 하드웨어 인증 장치가 이 키의 등록된 승인자인가"

[레벨 2] 실행 권한 — HSM 쿼럼 인증
   ├─ 하드웨어 인증 장치 2단 서명 (타임스탬프 + 챌린지)
   └─ 정책 객체 t-of-n HSM 내부 재계산
       "이 서명을 실제로 만들 수 있는가"

한 단이라도 끊기면 서명은 진행되지 않아요. 요청 권한과 실행 권한이 같은 정책 체계로 묶여 있어서, 한 곳에서 막히면 전체가 막혀요. 인증 세션이 살아 있어도 HSM 쿼럼이 안 채워지면 서명은 일어나지 않고, 쿼럼이 채워져도 호출 권한이 없으면 요청 자체가 도달하지 않아요.

정리해 보자면 이래요. 키 보관 중심의 일반적인 HSM 구성의 명제는 “권한을 가진 자가 서명한다”. 쿼럼 빌트인 HSM에서는 이 명제가 “정책을 만족한 다수 승인자만이 서명한다”로 바뀌고요. KODA 커스터디 코어는 그 보장 위에 단방향 QR 채널로 경계를 긋고, 승인자들이 흩어져 승인해도 되는 비동기 워크플로를 얹고, 요청 권한과 실행 권한을 2단으로 분리해서 — 이 전부를 단일 정책으로 묶은 통합 아키텍처예요.

4. 위협 모델 결산

KODA 커스터디 코어 시스템을 위협 단위로 짚어 볼게요. 공격 표면이 외부에서 내부로 들어오는 순서로 봅니다.

표를 보시면, 완화 통제의 절반은 채택한 HSM의 표준 기능이고, 나머지 절반은 그 위에 KODA가 얹은 통합 레이어와 운영 정책에서 나옵니다. 둘이 합쳐져야 단일 신뢰 경계가 완성돼요.

물론 시스템만으로 풀 수 없는 부분도 있어요.

• 물리 침해는 HSM의 변조 방지 설계에 의존합니다. 도입 시 해당 모델과 운영 모드의 보안 인증 범위를 확인했지만, 물리 보안은 결국 설비와 운영 절차가 함께 담당하는 영역이에요.
• QR 채널 운영 비용이 있어요. QR로만 통신하니 처리량과 운영 동선이 네트워크보다 무거워요. 고처리량 트랜잭션 환경에는 그만큼의 운영 설계가 따라붙어야 해요.
• 승인자 다수 담합은 거버넌스 영역이에요. HSM이 풀 수 없는 문제예요. 사람과 절차로 풀어야 합니다.
• 승인 화면과 실제 서명 대상의 일치는 payload 재구성 리뷰 절차로 관리하지만, 운영자 실수 가능성 자체가 사라지는 건 아니에요. 남은 위험은 절차와 교육으로 관리합니다.

한계를 명시한다는 것은 신뢰의 토대예요. 완화할 수 있는 것만 완화할 수 있다고 적는 게 정직한 위협 모델이에요.

5. 마치며: KODA 커스터디 코어가 서 있는 자리

시중 커스터디 논의는 보통 두 갈래예요. MPC 기반 커스터디는 키 분산 문제를 풀어요. 키를 조각내서 한 곳에 다 모이지 않게 하죠. 키 보관 중심의 범용 HSM 구성은 키 격리 문제를 풀어요. 키가 HSM 밖으로 나오지 않게 잠그죠. 둘 다 각자의 위협을 효과적으로 다뤄요. 다만 상당수 구성에서 이 서명이 조직적으로 적법한가의 판단은 호스트 소프트웨어 영역에 남기 쉬워요. 물론 제품과 구성에 따라 정책 통제를 함께 제공하는 경우도 있고요.

저희가 서 있는 자리는 그 사이의 빈자리예요. 쿼럼 빌트인 HSM을 채택해서 정족수와 정책 강제를 HSM 안으로 가져오고, 그 위에 단방향 QR 채널 + 비동기 다중 서명자 추적 모델 + 2단 인증(요청 권한·실행 권한 분리)을 통합 아키텍처로 얹어, 단독 내부자도, 호스트 침해도, 정책 변경자 = 서명자 시나리오도 — 단일 행위자나 단일 계층의 침해만으로는 비인가 서명이 성립하기 어렵게 설계했어요.

키를 잃는 것보다 무서운 건, 적법해 보이는 잘못된 서명이거든요. 그 서명을 만들지 못하게 하려고, 저희는 키를 지키는 데서 멈추지 않았어요. 정책을 HSM 안에서 강제하는 장비를 골랐고, 그 위에 비동기 운영 워크플로와 영역 분리, 인증 사슬을 얹었습니다. 세 방어선이지만, 단일 정책으로 묶여 있는 구조 — 그리고 그 주요 결정이 사후 추적 가능한 형태로 남는 구조 — 이게 KODA 커스터디 코어가 풀고 있는 문제예요.