[오프라인 CBDC] 네트워크 연결 없이 어떻게 CBDC를 주고 받을 수 있을까?
VISA 연구진 논문을 바탕으로 작성함 :
당신은 지금 아주 난감한 상황이다. 불과 삼십 분 전, 불금🔥이 무색하게 지나가는 택시를 바로 잡아 기분 좋게 집으로 향했다. 어느새 집 근처에 도착하여 주말을 맞이할 생각에 흥얼거리며 삼성페이를 켰는데…? ‘결제하려면 네트워크에 연결하세요’라는 안내 문구만 화면에 나올 뿐, 지문인식이나 생체인증이 뜨지 않는다. 뭐지. 화면 상단을 보니 5G는 커녕, 네트워크 신호가 아예 없다!
평소 외출시 휴대폰만 챙기는 당신은, 어서 결제하라는 택시 아저씨의 재촉과 뒷차의 빵빵거리는 소리에 정신이 혼미해진다… 😵
물론, 이러한 상황은 실물 카드나 현금을 들고 다닌다면 발생하지 않는다. 그러나 현금 없는 사회에 이어 현금 없는 매장도 속속들이 등장할 정도로, 소비자 뿐만 아니라 판매자의 현금 선호도 역시 감소 추세다. 또한 실물 카드의 경우, 전국 단위의 대규모 네트워크 장애 등 재난 상황에서는 마땅한 대안이 되지 않는다.
따라서 공공의 이익을 위할 의무가 있는 중앙은행은 CBDC 발행 시, 오프라인에서 거래할 방안을 마련해야 한다.
오프라인 CBDC 범위는 크게 3가지로, ➊ CBDC 계좌/전자지갑(온라인)에서 오프라인 저장매체로의 CBDC 이전, ➋ 오프라인 저장매체(카드)-가맹점 단말기 결제, 그리고 ➌오프라인 저장매체 간 CBDC 이전이다. 앞의 1, 2번 방식은 거래 주체 중 하나가 온라인임을 전제로 한다.
때문에 지엽적 혹은 전국적 문제로 네트워크 장애가 발생하는 경우, 3번이 유일한 결제 방법이다 (외상 또는 실물 화폐를 사용하지 않는다면 말이다.)
그러므로 본 글에서는 거래 쌍방이 모두 오프라인인 상황에서의 단말기간 CBDC 거래 방안을 살펴보겠다.
요약 (TEE + 암호화 프로토콜)
Visa 연구진은 네트워크 연결이 없는 상황(오프라인)에서의 CBDC 결제가 가능한 Offline Payment system(OPS) 프로토콜을 제안한다. OPS 프로토콜은 point-to-point(단말기간) 채널을 통해, 결제사업자의 중개 없이도 무한한 처리량 및 실시간 거래 처리를 지원한다. 연구진은 trusted execution environments (TEEs, 신뢰실행환경)가 생성한 디지털 서명을 통해 이중 지불 문제를 방지한다.
요즘 대부분의 모바일 기기 등에 탑재된 TEE를 오프라인 기기를 주요 신뢰 지점(Primary point of trust)로 삼고, 암호화 프로토콜을 통해 TEE 탑재 기기들 간 안전한 CBDC 교환을 가능하게 한다.
본 논문의 TEE 등록 및 암호화 프로토콜은 공개키 암호화 방식(public-key cryptography)을 활용한다. 공개키 암호화 방식은 흔히들 인터넷상에서 안전한 정보 전달 목적으로 사용한다.
CBDC 모델에서 화폐의 이동은 항상 신뢰받는 발행자(여기서는 중앙은행)의 채무(liability)이어야 한다. 그 말인 즉, 수신자가 화폐의 진위성을 쉽게 증명하는 이상 발행자가 화폐 가치를 항상 보증할 수 있어야 한다. 그럼으로써 ① 화폐가 사전 정의된 세부 규칙(통화정책)에 따라 올바르게 발행되고, ② 이동중에도 화폐의 가치를 보존(이중지불 또는 위변조 X)할 수 있다.
화폐는 공개키 인프라(public key infrastructure, PKI)에 기반하여, 중앙은행(직접) 또는 중앙은행의 인증된 위임기관(간접)만이 생성 가능한 디지털 서명을 가져야 한다. 그리고 화폐 수신자는 해당 디지털 서명을 중앙은행/위임기관의 공개키와 대조함으로써 인증할 수 있다.
OPS는 시큐어 하드웨어(모바일 기기)에 탑재된 TEE 보안 환경을 통해, 사용자 CBDC 보관 및 중앙은행/위임기관 인증서를 활용한 오프라인 결제를 진행한다.특히 요즘 모바일 기기는 제조사의 도움 없이는 조작/해킹이 어렵기 때문에, 시큐어 하드웨어가 안전한 이상 1. 오프라인 결제를 서명하는 키에 대한 악성 접근 차단과, 2. 이중지불 방지 가능하다고 볼 수 있다.
솔루션 개요
OPS 프로토콜 목표
클라이언트 A(송신자)와 B(수신자) 모두 S서버와 통신 없이, 서버S 내 A계좌에서 B계좌에 금액 x를 이전
몇 가지 전제
- 클라이언트 A, B는 서버 S에 온라인 계좌를 보유한다. 해당 계좌는 클라이언트가 S에 보유한 잔고 정보를 가진다.
- 서버S는 전자지갑 제공자로서, CBDC 계층 신뢰 인프라(앞서 본 2 tier 모델)를 통해 중앙은행으로부터 디지털 인증서를 획득했다. 동인증서는 클라이언트에게 S가 신뢰할 수 있는 주체임을 입증한다.
- 송신자A는 시큐어 디바이스 D(A)를 가진다. D(A)는 TEE로 데이터를 안전하게 저장하고 코드를 실행한다. 수신자B는 시큐어 디바이스를 가질 필요는 없다.
솔루션 구성
① TEE 모델
- TEE는 시큐어 디바이스 내 읽기전용메모리(ROM)에 저장된 소프트웨어 스택이다. 스택은 시큐어 디바이스에 접근하기 위한 리소스, 개발자들이 시큐어 디바이스에 접근할 수 있는 trusted operating system(TOS), 그리고 TEE의 안전한 실행을 위한 전용 어플리케이션 trusted applications(TA)가 하나 이상 있다.
② Untrusted Applications(UA)
- 디바이스 내 “신뢰할 수 없는” 지역에 위치한 어플리케이션으로 악성일 수 있다. UA는 결제 수신, 검증 및 저장하는 사용자화 기능을 제공한다. 또한 클라이언트가 온라인일 때면 서버로 결제 내역을 제출한다.
③ OPS Components
- OPS Server TA : 서버에 배포되어 클라이언트 디바이스 세팅 및 클라이언트 계정 관리 기능 제공
- OPS Sender UA : 송신자 디바이스에 배포되어(deployed) OPS TA와 상호작용을 통해 오프라인 결제를 생성하고, 서버와 상호작용하여 UA 및 TEE를 등록하는 OPS 사용자 인터페이스 제공
- OPS Receiver UA : 수신자 디바이스에서 실행되어, 오프라인 결제를 수신및 검증하고, S와 상호작용하여 UA 등록 및 오프라인 결제를 청구(claim)하는 OPS 인터페이스 제공. TEE와 상호작용하지 않음. 수신자가 다른 클라이언트로부터 화폐를 받고 싶다면 자신의 디바이스에 OPS Receiver UA 설치 필요
- OPS TA : TEE 내 송신자의 시큐어 디바이스에서 실행되어, 시큐어 디바이스 접근 및 클라이언트 오프라인 잔고 관리를 위한 OPS-특화 기능을 제공. 클라이언트 A의 디바이스에서 실행되는 TA를 T(A) 표기
④ 프로토콜
다음 프로토콜 중 본 글에서는 A. 셋업, C. 오프라인 결제 프로토콜만을 다루려고 한다. 기타 프로토콜은 논문을 참조하기를 바란다.
- A. Setup Protocol
- B. Deposit Protocol
- C. Offline Payment Protocol
- D. Claim Protocol
- E. Collect Protocol
- F. Withdraw Protocol
⑤ Replay/Rollback Protection
모델
OPS(offline payment system, 오프라인 결제 시스템)은 다음 성질을 만족한다 :
- 오프라인 검증 가능성(verifiability) : 수신자는 결제 과정에서 서버 통신 없이도 결제의 진위성을 자체적으로 검증 가능해야 함.
- 절대적 완결성(finality) : 결제가 완료되는 즉시, 수신자는 이전된 금액에 대한 소유권을 보장 받아야함.
- 온라인 변제 가능성(Redeemability) : 클라이언트 A는 오프라인 잔고에서 잔액 이하만큼의 금액을 온라인 잔고로 바꿀 수 있어야 함.
- 오프라인 전이성(Transitivity) : 오프라인 결제를 받으면, 수신자는 해당 결제액을 동일한 오프라인 세션에서 사용할 수 있어야 함. (온라인에서 변제할 필요 없이)
- 보안성(security) : OPS는 다음 성질을 만족하면 안전하다
1. 이중지불 방지. 악성 클라이언트는 동일한 결제를 두 번 이상 반복할 수 없음
2. 지갑 보안성 : 악성 클라이언트는 다른 클라이언트 동의 없이 해당 클라이언트 지갑에서 돈을 사용하거나 제거할 수 없음.
3. 공급 보존 : 시스템내 화폐 총공급량은 항상 동일하다. 다시 말해, 클라이언트는 서버에서 제공한 예치/인출 기능을 통해서만 시스템에 화폐를 증감시킬 수 있다.
오프라인 결제를 원하는 클라이언트A는 오프라인 잔고 offBal(A)를 안전하게 보관하기 위해서는 TEE가 적용된 시큐어 디바이스 D(A)가 있어야 한다. 이는 T(A)가 D(A)내에 보관된 비밀키 sk(A)로 생성한 디지털 서명을 통해 이뤄진다.
TEE 모델
TEE는 독립된 실행 환경으로 안전하게 보호된 하드웨어 자원 및 운영체제 trusted application(TA)로 구성된 소프트웨어 스택을 가진다. TEE는 무결성과 신뢰성을 보장하며, 허가 없는 TA 접근은 금지된다.
운영체제는 외부 프로그램(untrusted application, UA)에서 API를 통해 TEE 내의 퍼블릭 TA 함수를 호출 및 실행하도록 허용한다.
본 논문에서는 ARM TrustZone 기술이 차용한 표준화 TEE모델인 GlobalPlatform(GP)를 활용한다. 오늘날 대부분의 안드로이드 스마트폰이 해당 기술을 사용한다. GP의 안전한 저장 모델을 통해 OPS TA 스테이트 롤백을 방지할 수 있다. (생략)
OPS 프로토콜
1. 클라이언트 셋업
- 모든 클라이언트(TEE 기반이든 아니든)는 일회성(one-time) 셋업 프로토콜을 통해 서버에 기기를 등록(암호키 및 인증서 발급)하고 기기의 TEE 스택을 초기화 해야 한다.
- 절차는 다음과 같다 :
[클라이언트] 로컬 서명 키페어(vk, sk)를 생성하고 검증키를 서버에 제출 ➞ [서버]클라이언트 계좌 정보 초기화 및 클라이언트에게 인증서 리턴 - 이때 인증서(certificate)는 클라이언트의 검증키에 대한 서버의 서명이다. 등록 시, 서버는 클라이언트의 검증키를 레지스트리에 보관하여 동일 클라이언트의 중복 등록을 방지한다. 또한 클라이언트의 온라인 잔고를 ‘0’으로 초기화 한다.
TEE를 사용하는 클라이언트는 다음 방법으로 TEE를 세팅 한다 :
(1) TEE Remote Attestation(원격 입증)
- TEE를 세팅하기 위해서는 TEE OEM사의 인증이 필요하다. OEM사는 TEE 하드웨어와 trusted OS의 손상 여부를 검증한다. 해당 작업은 읽기전용메모리(ROM)과 기기의 디바이스 키페어(D.vk, D.sk)로 이루어진다. ROM과 키페어 모두 OEM사에 의해 하드웨어에 임베드되었기 때문에 trusted OS의 서명과 D.vk를 검증함으로써 해킹 여부를 확인할 수 있다.
(2) OPS TA Provisioning
- 위의 절차를 통해 TEE가 승인되면, 다음으로 OPS TA 프로그램이 TEE 내에 제대로 프로비전(배포)되었는지 확인해야 한다.
확인은 로컬 혹은 원격 프로비저닝을 통해 가능하다. 먼저 로컬 프로비저닝에서는 OEM사가 TEE 소프트웨어 스택의 일환으로써 TA 바이너리를 기기에 담는다.
한편 리모트 프로비저닝에서는 TEE 승인이 이루어지면 신뢰기관이 TA를 원격으로 배포한다. 해당 작업은, 기기의 검증 키를 활용해 TEE와 시큐어 채널을 만들고 ➞ 채널을 통해 TEE에 TA 바이너리를 전송하는 방법으로 진행된다.
2. OPS TA 등록
앞의 두 단계를 통해 TEE가 승인되고(remote attestation) OPS TA가 TEE내에 프로비전 하여 TEE를 초기화(initialize)했다.
다음으로 클라이언트 기기 및 OPS TA 인스턴스를 서버에 등록할 차례다 :
- 먼저 OPS TA는 서명 키페어(T.vk, T.sk)를 생성하고 클라이언트 기기에 검증키 및 원격 입증 결과를 리턴한다.
- 다음으로 클라이언트는 TA 검증키와 입증 결과를 기기 정보와 함께 서버에 전달한다.
- 서버는 입증 결과를 검증하고 서버의 비밀키로 서명하여 인증서를 리턴하다.
- 클라이언트 기기의 TEE 내 OPS TA는, 서버로부터 인증서를 받은 이후에 활성화된다.
- 서버는 각 OPS 클라이언트에 대한 카운터를 초기화 한다. 클라이언트의 OPS TA 역시 카운터 역할을 하는 내부 변수를 가지는데, 두 카운터 싱크(sync)를 맞춤으로써 이중지불 등의 문제를 방지할 수 있다.
3. 오프라인 결제 프로토콜
OPS의 핵심인 오프라인 결제 프로토콜으로, 오프라인에서 클라이언트 A가 B에게 CBDC를 지급한다.
[오프라인 CBDC 지급]
- 먼저 결제 수신자B가 자신의 인증서가 포함된 결제 요청 [RequestPayment, x, receiver]을 송신자에게 전달한다.
- 요청을 받은 송신자A는 OPS TA상의 Pay 함수를 실행하며, OPS TA는 A의 오프라인 잔고가 충분한지 확인한다.
충분하다면, OPS TA는 클라이언트의 오프라인 잔고에서 x만큼을 차감한 뒤 결제 컨펌을 생성한다. 이때 결제 컨펌에는 송/수신자 모두의 인증서, 결제 카운터 j, OPS TA의 서명이 포함된다. - 결제 컨펌을 받으면, 수신자B는 인증서와 디지털 서명을 검증하여 결제 유효성을 확인한다. 또한 결제 수신자가 B임을 확인하여 이중지불 시도를 방지한다.
모든 확인이 끝나면, 수신자는 자신의 결제 로그에 정보에 해당 결제를 추가하고, 서버S에 [ReceivedPayment] 컨펌 메시지를 전달한다.
[오프라인 CBDC 수신]
송신자가 오프라인 CBDC를 획득하는 방법은 송신자의 TEE 사용 여부에 따라 달라진다.
a. TEE 사용하는 클라이언트 : Collect 프로토콜 실행
b. TEE 없는 클라이언트 : Claim 프로토콜 실행.
[컨펌]
결제 컨펌 시 전달되는 송/수신자의 인증서는 해당 결제가 서버에 등록된 송신으로부터 온 진짜 거래임을 보증한다. 지급 시 호출하는 OPS TA의 Pay 함수는 카운터를 증가시키는데, 이를 통해 TEE가 생성한 결제 컨펌은 항상 고유하다. (적어도 카운터 값이 달라지기 때문)
디지털 서명을 통해 OPS TA가 보낸 컨펌 진위성을 확인하고, 디지털 서명이 바뀌지 않는 이상 클라이언트는 컨펌 내용(금액, 송/수신인 인증서, 카운터)을 수정할 수 없다.
맺음말
이상 네트워크가 없는 상황에서도 오프라인 CBDC 결제가 가능한 방법을 알아보았다. 사용자 디바이스를 primary point of trust로 활용함으로써, 국소적인 통신 에러 상황 뿐만 아니라 재난 상황(자연 재해 등) 또는 깊은 산 속 같이 통신 불가 지역에서도 결제(p2p)가 가능해진다. 오프라인 결제가 가능해야 국민들은 어떤 상황에서든 지급결제 시스템에 접근 가능하다.
한국은행은 금번 CBDC 모의실험 입찰 공고에 ‘오프라인 CBDC 결제’를 범위에 포함하였다. 그리고 삼성전자의 갤럭시폰 및 갤럭시워치가 오프라인 CBDC 결제 디바이스로 활용될 예정이다.
다만 논문에서는 시큐어 하드웨어를 고의적으로 손상(compromise)시켜 CBDC를 위조하거나 무한히 이중지불하는 경제적 유인(incentive)가 매우 크다는 문제를 지적한다. VISA 연구진은 이에 대해서는 후속 연구에서 경제적 유인, 단계적 성능 저하(graceful degradation), CBDC 복구에 대해 탐구한다고 한다. 👀
- CURG(Crypto United Research Group)는 2018년 5월 대학(원), 기업, 스타트업 등 다양한 분야의 열정적인 블록체인-er들이 모인 연합 연구 그룹입니다. CURG는 2018년 5월 출범된 이후, ‘Trendy, Thoughtful, and Transdisciplinary’ 한 자세로 한 주도 빠짐없이 블록체인 연구를 지속해오고 있습니다.
- 디사이퍼(DECIPHER)는 “건강한 블록체인 생태계 조성에 기여한다” 라는 미션 아래 블록체인에 대해 연구하고 이를 실용적으로 응용하는 서울대 블록체인 연구 학회입니다. 2018년 3월에 처음 조직 되어 현재까지 블록체인 기술을 다방면에서 연구하고 산업계에 응용하고 있는 100명 이상의 회원들을 배출해왔습니다. 다양한 팀별 연구활동과 프로젝트, 컨퍼런스 개최, 서울대학교 블록체인 강의 개설, 유수 기업들과의 산학협력과 파트너십 체결을 해오며 국내 최고의 블록체인 학회로 자리 잡았습니다.
커그와 디사이퍼는 향후 적극적인 협력을 통해 블록체인 필드에서의 강력한 시너지를 구축하고자 합니다.
