zk-LTARK의 개인키 취약점을 개선한 UTXO 기반 프라이버시 보장 CBDC 시스템

Privacy-Preserving UTXO-Based CBDC System Mitigating zk-LTARK Private Key Vulnerability

Abstract

전 세계적으로 디지털 전환이 가속화되고 탈중앙화 디지털 화폐의 거래량이 급증함에 따라, 각국 중앙은행은 중앙은행 디지털화폐(CBDC) 관련 연구를 활발히 진행하고 있다. CBDC의 보안 요구사항을 충족하기 위해 Islam[3]은 zk-LTARK 영지식 증명을 활용한 CBDC 시스템을 제안하였다. 그러나 본 연구는 Islam이 제안한 CBDC 시스템에서 개인키 재사용으로 인한 개인키 노출 취약점을 발견하고 이를 수학적으로 증명하였다. 이러한 취약점을 해결하기 위해 본 논문에서는 임시(ephemeral) 개인키 사용과 페더슨 커밋먼트(Pedersen commitment) 기법을 활용하여 거래금액까지 숨기고, 거래 당사자만 거래 금액 정보를 알 수 있는 개선된 CBDC 시스템을 새롭게 제안한다. 끝으로, 본 논문은 CBDC 시스템에서 요구되는 프라이버시(privacy), 감사가능성(auditability), 투명성(transparency)을 모두 만족 가능한 가운데, 사용자 간 결제 진행이 가능함을 시스템 및 보안 분석을 통해 보인다.

With the rapid growth of decentralized digital currency transactions, central banks are actively investigating Central Bank Digital Currency (CBDC). To meet the security requirements of CBDC, Islam[3] proposed a CBDC system based on zk-LTARK zero-knowledge proofs. However, we identify and mathematically prove a vulnerability in this system arising from private key reuse, which may lead to private key exposure. To address this vulnerability, we propose an enhanced CBDC system that employs ephemeral private keys and the Pedersen commitment scheme to conceal transaction amounts, ensuring that only the transacting parties can know the amount of the transaction. Finally, through system and security analysis, we demonstrate that the proposed CBDC system enables peer-to-peer payments while simultaneously satisfying privacy, auditability, and transparency.

I. 서론

전 세계적으로 금융 및 경제 부문의 디지털 전환(digital transformation)이 가속화되면서 현금 사용 감소세가 지속되고 있다. 이와 함께 분산원장기술(distributed ledger technology)을 활용한 비트코인[1]과 같은 탈중앙화 디지털 화폐의 거래량이 급증하고 있다. 이처럼 변화하는 금융 환경에서 각국 중앙은행은 통화정책 수립 및 적용이 용이하며, 지속 가능한 금융 시스템 생태계를 조성할 수 있는 중앙은행 디지털화폐(Central Bank Digital Currency; CBDC) 관련 연구를 활발히 진행하고 있다[2].

CBDC는 중앙은행이 발행하고 유통하는 국가 단위의 디지털 화폐로써, 기존 법화 형태만 변화한 것일 뿐 동일한 화폐가치를 지닌다. CBDC 시스템에 필요한 보안 요구사항에는 프라이버시(privacy), 투명성(transparency), 감사가능성(auditability)이 있다[3]. CBDC 시스템과 같은 결제 시스템(payment system)에서 프라이버시란, 사용자의 거래 내역 등 개인정보의 노출을 방지하는 것을 말한다. 투명성은 모든 거래 내역을 포함한 원장(ledger)을 시스템 참가자 모두에게 공개하고, 검증할 수 있도록 시스템을 설계함으로써 보장 가능하다. 감사가능성은 자금세탁(money laundering), 조세회피 등 악의적인 거래 내역이 존재할 경우 해당 거래내역 또는 사용자에 대해 감사(auditing) 활동이 가능하도록 보장하는 속성을 말한다[4].

2024년 Islam[3]은 프라이버시, 투명성, 감사가능성을 충족함과 동시에 CBDC의 성능 개선을 고려하여 영지식 증명을 경량화한 zk-LTARK(zero knowledge Lightweight Transparent ARguement of Knowledge)를 활용한 CBDC 시스템을 제안하였다(2.4 영지식 증명 참고). [3]은 zk-LTARK 영지식 증명 프로토콜을 활용하여 사용자가 CBDC 코인을 송신할 때, 사용자의 신원을 노출하지 않고, 본인이 사용할 코인의 소유권을 증명할 수 있는 CBDC 시스템을 제안하였다.

본 논문은 [3]에서 제안한 CBDC 시스템의 보안성 분석 수행 등 CBDC 시스템의 보안 요구사항을 모두 만족 가능한 시스템 설계 방법을 탐구하였다. 특히, [3]에서 제안한 CBDC 시스템에서 CBDC 네트워크 내의 악의적인 CA로부터 [3]이 제안한 zk-LTARK 영지식 증명을 활용하여 사용자의 개인키가 노출될 수 있는 취약점과 공개된 거래 금액을 활용하여 거래 연결 및 추적이 가능하다는 취약점을 발견하였다. 본 연구는 이러한 취약점을 해결하기 위해, 일회용 개인키와 커밋먼트(commitment)를 활용하여 CBDC의 보안 요구사항을 충족 가능한 CBDC 시스템을 새롭게 제안한다. 끝으로, 본 논문에서 제안하는 CBDC 시스템은 프라이버시, 투명성, 감사가능성을 모두 만족한 가운데 사용자 간 거래 수행이 가능함을 보인다.

II. 배경지식

2.1 CBDC

CBDC는 중앙은행이 직접 통화정책의 목적에 따라 발행·유통하는 법정 통화의 디지털 형태로, 비트코인(Bitcoin)[1], 이더리움(Ethereum)[5] 등 퍼블릭 블록체인(public blockchain) 기반 디지털 화폐와는 분명한 차이점이 존재한다. 퍼블릭 블록체인은 누구나 노드로 참여해 거래를 생성·검증하고, 모든 거래 내역을 열람할 수 있다. 이는 거래 투명성 측면에서는 장점이지만, 네트워크 참여자가 불특정 다수라는 특성 때문에 규제 준수 및 감사 절차가 어렵다는 한계점이 존재한다. 본 논문은 앞에서 설명한 퍼블릭 블록체인과 허가된(permissioned) 사용자(또는 기관)만 접근 가능한 프라이빗(private) 블록체인의 중간 형태인 컨소시엄 블록체인(consortium blockchain)을 활용하여 CBDC 시스템을 설계하고자 한다. 본 논문의 CBDC 시스템에서 합의 노드는 아래와 같다.

• (Central Bank; CB) : CB는 중앙은행으로, 통화정책을 수립하고 CBDC를 직접 발행·유통하는 유일한 객체이다.

• (Certificate Authority; CA) : CA는 시중은행 등 승인된 기관으로, CB와 함께 사용자가 생성한 거래를 검증하며 합의(consensus)과정을 거친다.

본 논문은 컨소시엄 기반 블록체인을 기반으로 CB와 CA가 CBDC 네트워크에 참여하고, 공동으로 합의 프로토콜(consensus protocol)을 수행한다. 본 논문에서의 합의 프로토콜은 일반적인 블록체인 노드 간 합의를 의미하는 것이 아니라, CB와 CA가 하나의 거래에 대해 순차적으로 검증을 수행하고, 두 검증 결과가 모두 참일 때 해당 거래가 합의되어 원장에 기록된다. 이는 퍼블릭 블록체인 대비 빠른 감사가능성을 제공하면서도 프라이빗 블록체인에서 발생 가능한 단일 기관에 대한 의존성을 줄여 높은 신뢰성을 확보할 수 있다.

2.2 결제 시스템의 분류

CBDC 시스템은 크게 UTXO기반 CBDC와 계좌(account) 기반 CBDC로 구분 가능하다. 암호화폐에서 사용하는 미사용 거래 출력(Unspent Transaction Output; UTXO)이란, 특정 사용자 주소로 일정 금액을 전송하는 거래를 마친 후 남는 출력(output)을 의미한다. UTXO 기반 거래 구조에서 출력에 기록된 코인은 이후 다른 거래의 입력(input)으로 사용할 수 있다. 따라서 사용자가 사용할 수 있는 잔액(balance)은 기존 거래에서 생성된 UTXO의 총합이다. UTXO 기반 거래구조에서는 입력값 코인 금액의 총합과 출력값 코인 금액의 총합이 일치해야 한다. 이때, 각 거래는 독립적으로 미사용 거래 출력을 소비하고 새로운 미사용 거래 출력을 생성한다. 특정 거래가 참조하는 출력은 다른 거래와 중복되지 않으므로, 다른 거래를 병렬적으로 동시에 검증할 수 있다. 반면, 계좌 기반 거래 구조는 계좌별 잔액을 전역 상태(global state)에서 순차적으로 갱신하는 방식이다. 이 구조는 각 거래의 병렬 처리가 어렵다는 단점이 있다.

본 논문은 컨소시엄 블록체인 기반 UTXO형 CBDC 시스템에 한정하여 설계한다.

2.3 ECC와 DDID

타원곡선암호(Elliptic Curve Cryptography; ECC)는 유한체(F_p) 내에서 정의되는 타원곡선(E_d)에서의 이산대수 문제를 기반으로 하는 암호 기법이다. ECC는 RSA[6] 같은 전통적인 암호 기법에 비해 짧은 키 길이를 사용하여 저장 효율성이 뛰어나다는 장점을 가진다[7,8]. 본 논문의 주요 분석 대상인 [3]에서는 Twisted Edwards form 곡선인 Ed25519 타원곡선[7]을 사용하며, 타원곡선 생성 방법은 수식 (1),(2)와 같다.

E_d = -x² + y² = 1 + dx²y²       (1)

d = (-121665/121666)%p       (2)

위 곡선은 아핀좌표계(affine coordinates)를 쓰는 다른 곡선과 달리, 혼합좌표계(projective coordinates)를 활용하여 점 덧셈(point addition)및 스칼라 곱셈(scalar multiplication)을 사용하여 고비용의 모듈러 연산을 최소화함으로써 전체 연산비용을 낮출 수 있다. [3]은 해당 곡선을 활용하여 사용자의 키 쌍과 각 거래 수행마다 일회성으로 분산식 식별자(Disposable Decentralized Identifier; DDID)를 생성함으로써 사용자의 신원을 노출하지 않고도 거래를 수행할 수 있는 CBDC 시스템을 제안하였다.

본 논문은 [3]과 동일하게 DDID 인증을 위해 EdDSA(Edwards-curve Digital Signature Algorithm)를 사용한다. EdDSA는 32바이트 길이의 안전한 난수로 이루어진 개인키를 활용하여 서명을 생성 및 검증한다. 개인키는 SHA-512와 같은 해시 함수를 통해 64바이트의 해시값으로 확장되며, 이 해시값은 두 부분으로 나뉘어 사용된다. 전반부 32바이트는 클램핑(clamping) 과정을 거쳐 검증키 생성을 위한 스칼라값으로 변환되고, 후반부 32바이트는 서명 과정에서 메시지(m)별 일회성 난수를 결정론적으로 생성하기 위한 프리픽스(prefix)로 활용된다[17]. EdDSA는 특정 m와 σ_CA에 사용된 특정 검증키를 결속(binding)하기 위하여 검증키를 서명 생성 과정의 입력값으로 사용하는 것이 특징이다. 이는 보드네(Vaudenay) 공격과 중복 키 공격(duplicate key attack)를 방지한다[22].

본 장에서는 키, DDID 생성, EdDSA 서명 생성 방식을 총 5가지의 알고리즘으로 설명하도록 한다[3].

1) EC.Setup(1^λ) : 타원곡선의 보안 상수(1^λ)를 입력받아 시스템 파라미터(pp)를 생성한다.

2) EC.KeyGen(sk_u;pp) : 사용자는 타원곡선의 기저점(P)의 차수(p) 범위 내 임의의 난수를 뽑아 개인키(sk_u (or sk′_u)∈F_p )로 사용하며, 사용자의 sk_u와 pp를 활용하여 사용자의 공개키(pk_u (or pk′_u∈E_d(F_d))를 생성한다[3].

3) EC.DDIDCGen (sk'_u;pp) : 사용자는 자신의 임시 개인키(sk′_u)와 임의 공개키(H)를 활용하여 일회용 주소(DDID_u (=sk'_u ∙ H))를 생성한다[3].

(단, 본 논문은 [3]의 알고리즘과 달리, 매 거래마다 새롭게 생성한 sk'_u와 고정된 H를 활용한다.)

4) EC.Sign(m;sk_CA,vk_CA) : CA는 사용자로부터 m를 전달받고, CA의 서명용 개인키(sk_CA)와 검증키(vk_CA)를 활용하여 σ_CA을 생성한다[17].

5) EC.Verify(σ_CA, m;vk_CA) : σ_CA, m, vk_CA를 입력 받아, True 혹은 False를 반환한다[17].

2.4 영지식 증명(Zero Knowledge Proof)

영지식 증명이란, 증명자(prover)가 자신이 소유한 지식이나 정보를 공개하지 않고도 검증자(verifier)에게 해당 지식을 알고 있음을 증명할 수 있는 기술을 말한다. 이와 같은 영지식 증명은 다음과 같은 세 가지 속성을 모두 만족 가능하여야 한다.

• 완전성(completeness): 정직한 증명자가 검증자를 설득할 수 있음을 보장 가능하다.

• 건전성(soundness): 거짓된 증명자가 검증자를 속일 수 없음을 보장 가능하다.

• 영지식성(zero-knowledge proof): 검증자가 증명자가 증명하는 값의 참 여부 외의 다른 어떠한 정보도 알지 못함을 보장 가능하다.

CBDC 시스템에서 프라이버시를 만족하기 위해 영지식 증명을 활용하면, 각 거래(transaction)에 포함된 내용을 노출하지 않으면서 거래의 유효성을 검증자에게 증명할 수 있다[4]. 본 논문은 DDID 생성과정 및 거래의 유효성을 위해 영지식 증명을 활용하며, 해당 과정에 대한 보안분석은 후속 장에서 다루도록 한다(5.1 보안분석 참고). 본 논문은 기본적으로 Schnorr 기반의 시그마 프로토콜 영지식 증명[9]을 사용하며, 3가지의 알고리즘으로 구성된다.

1) ZK.Setup(1^λ) : 1^λ를 입력받아 시스템 파라미터(pp_ZK)를 생성한다.

2) ZK.Prove(pp_ZK, x, w) : 시스템 파라미터(pp_ZK), 공개값(x), 비밀값(w)을 입력받아 영지식 증명값(π)을 생성한다[9,10].

3)ZK.Verify(pp_ZK, x, π) : pp_ZK, x, π을 입력받아 True 혹은 False를 반환한다[9,10].

2.5 페더슨 커밋먼트

페더슨 커밋먼트(Pedersen commitment)[11]는 어떤 값을 숨기되, 나중에 그 값이 올바른지 증명할 수 있는 암호학 기법이다. 본 논문에서는 거래 금액과 DDID와 같은 정보를 숨기는 데 사용한다.

본 논문에서는 거래 금액(Amount)을 숨기기 위해 페더슨 커밋먼트 기법을 사용하며, 다음 4개의 알고리즘으로 구성된다.

1) CM.Setup(1^λ) : 보안 상수 1^λ를 입력받아 F_p와 E_d의 기저점 P, Q, U를 설정한다. 이때 Q와 U는 P와 선형 종속되지 않는 별도의 기저점이다[11].

2) CM.Com(m,r) : 메시지(m), 난수(r)를 입력받아 커밋먼트(Com)을 수식(3)과 같이 계산한다[11].

Com = m ∙ Q + r ∙ U (mod q)       (3)

3) CM.Verify(Com,m,r) : Com, m, r을 입력받아 수식 (3)이 성립하면 True 그렇지 않으면 False를 반환한다[11].

4) CM.ReRand (Com,r') : Com, 또 다른 난수 (r′)을 입력받아 수식 (4)와 같이 계산하여 재난수화 된 커밋먼트(Com')을 생성한다[18].

Com' = m ∙ Q + r' ∙ U (mod q)       (4)

페더슨 커밋먼트는 다음과 같은 성질을 가진다.

• 은닉성(Hiding): m과 r을 입력값으로 생성한 Com에 대해, Com만으로는 m을 알 수 없다.

• 결합성(Binding): 동일한 Com를 생성하는 서로 다른 (m,r)쌍이 존재할 수 없다. 즉, 위조 불가하다.

• 동형성(Homomorphism): Com₁, Com₂에 대해 수식 (5)가 성립하므로, 덧셈 동형성(additively homomorphism)을 갖는다.

Com₁ + Com₂ = (m₁ + m₂) ∙ Q + (r₁ + r₂) ∙ U       (5)

본 논문에서는 페더슨 커밋먼트를 활용하여 거래 금액을 은닉하면서도, 영지식 증명 기법을 결합하여 송신자가 생성한 거래의 유효성을 증명할 수 있는 구조를 제안한다. 이를 통해 거래 프라이버시 보호와 투명한 검증 가능성을 동시에 만족시킬 수 있다.

III. 관련연구

신뢰 가능한 전자 화폐 시스템을 위해 다양한 보안 관련 연구들이 제안되어 왔다. 특히, 비트코인[1]은 대표적인 공개형 블록체인 기반 결제 시스템으로서, 금융 기관과 같은 중앙화된 객체 없이 송신자와 수신자 간 직접 거래를 수행할 수 있는 시스템으로서 제안되었다. 시스템 내의 모든 거래는 해시 기반 작업 증명(Proof-of-Work)을 포함한 시스템 참여자들의 합의를 통해 이중지불(double-spending) 문제를 해결하였다. 그러나, 거래 내용(특히 송신자, 수신자 주소)이 시스템 참여자 모두에게 공개되는 구조를 갖고 있어, 공개된 정보를 통해 누구나 거래 추적이 가능하기 때문에 거래의 프라이버시가 요구되는 결제 시스템에서 활용하기에는 부적합하다는 한계가 있다.

Ben-Sasson 등[12]은 zk-SNARKs[13]를 활용한 프라이버시 강화 전자 화폐 모델을 제안하였다. [12]에서는 [1]과 같은 퍼블릭 블록체인에서 충족하지 못하는 거래 시스템의 프라이버시를 보장 가능한 시스템을 제시하였다. 그러나, 거래 내용 자체는 완벽한 프라이버시를 보장하는 반면, CBDC 시스템에서 요구하는 감사가능성을 만족할 수 없어 CBDC 시스템 모델로 활용할 수 없다는 한계점이 존재한다.

이와같은 전자 화폐의 보안성 강화를 위한 연구와 함께 CBDC의 보안 요구사항을 만족시키기 위한 다양한 CBDC 시스템이 제안되었다. Wüst 등[4]은 난수를 활용한 영지식 증명을 송신자와 수신자 사이에 적용 시킴으로써 비연결성 거래(unlinkable transaction)를 정의하고 프라이버시가 강화된 CBDC 모델을 제안하였다. 그러나, [4]는 계좌 기반 거래 시스템을 채택하였기 때문에 CB가 검증작업 수행 시 병렬작업이 제한되어 거래 생성으로부터 거래 검증 및 발행까지 UTXO 시스템에 비해 상대적으로 효율성이 떨어진다는 한계점이 존재한다.

[14]는 페더슨 커밋먼트를 활용하여 거래의 프라이버시를 보장하고, 익명성 예산(anonymity budget)이라는 구조를 활용하여 ‘최대 송신 금액 한도 제한’ 정책이 포함된 CBDC 시스템을 제안하였다. 그러나, [14]에서는 감사자(Auditor)가 감사 활동을 수행하기 위해서는 사용자가 자발적으로 거래 정책 미준수 사실을 감사자에게 자진 신고해야만 감사 활동이 가능한 구조를 갖고 있다. 따라서, 수동적인(passive) 감사 활동만 수행 가능하다는 한계점이 존재한다.

[3]은 zk-LTARK를 활용한 효율적인 UTXO의 소유권 검증 메커니즘을 포함한 CBDC 시스템을 제안하였다. 특히, CBDC 시스템에서 요구하는 프라이버시와 감사 가능성을 모두 충족시키기 위한 시스템을 제안하였다. 이를 위해, [3]의 이전 논문인 [21]과 달리 완전한 탈중앙화 구조이며, 일회성 주소를 사용한다. 본 논문에서는 [3]에서 제안된 CBDC 시스템에 대해 보안 분석을 수행을 통해, 사용자의 신원 검증을 수행하는 CA가 사용자의 개인키를 추출 가능한 취약점의 존재와 거래 금액이 공개됨에 따른 한계점을 확인하였다(4.2, 4.3 참고).

본 논문에서는 CBDC 시스템의 보안 요구사항 관점에서 앞선 관련연구에서 충족할 수 없었던 CBDC 시스템 보안 요구사항을 모두 개선 또는 충족 가능한 시스템을 제안한다. Table 1.은 CBDC 관련 연구와 본 논문을 보안성 관점에서 비교한 표이다.

Table 1. Comparison of security features in CBDC systems

IV. 시나리오

본 장에서는 송신자가 자신의 CBDC 코인을 수신자에게 송금하는 시나리오를 바탕으로 시스템을 설명한다. 송신자는 자신의 200코인이 담긴 UTXO 2개를 사용하여, 300코인을 수신자에게 송금하고, 1코인을 수수료로 지불한 뒤, 99코인을 반환받는다. 본 논문은 보안분석을 통해 기존 [3]의 CBDC 시스템에서 개인키 추출 공격이 가능함을 보이고, 거래의 프라이버시 보장 관점에서 한계점이 존재함을 보인다. 끝으로, 제시한 한계점에 대한 해결방안을 제시하고자 한다. 본 논문에서 사용되는 용어는 Table 2.과 같다.

Table 2. Notation

4.1 기존 [3]의 CBDC

[3]은 컨소시엄 블록체인 기반 UTXO형 CBDC를 사용한다. [3]의 CBDC에서 등장하는 객체는 사용자, CA, CB로 구성되고, 사용자는 송신자(Sender)와 수신자(Receiver)로 구성된다. 각 객체의 역할은 다음과 같다.

• 송신자(Sender) : 자신의 UTXO를 소비하여 거래를 생성한다.

• CA : 사용자 등록 및 인증을 담당하며, CB가 검증 완료한 거래에 대하여 검증을 진행한다(블록체인의 노드 역할).

• CB : 시스템 내 정책(거래 수신금액 한도 제한 등)을 수립하고 CBDC를 발행 및 유통한다. 또한, 송신자가 생성한 거래에 대하여 검증하고, 해당 거래를 브로드캐스트(broadcast) 하여 CA에게 전달한다.

• 수신자(Receiver) : 검증 완료된 거래를 수신한다.

[3]의 시스템은 크게 ‘사전 거래(사용자 등록)’,‘거래 생성’, ‘거래 검증’, ‘거래 수신’ 총 네 가지 세부 절차를 통해 운영된다. [3]의 시스템에서 거래의 구조는 Fig. 1.과 같다.

Fig. 1. The construction of Islam‘s transaction

• 사전 거래(사용자 등록) : 사용자는(sk_u, pk_u), (sk'_u, pk'_u)와 DDID^State_{(3, j)}(=sk'_u ∙ H³)를 생성하고, 자신의 사용자 등록 담당 CA로부터 DDID^State_{(3, j)}에 대한 σ^CA_(3,j)을 받는다[3].

• 거래 생성 단계 : 송신자는 수신자로부터 DDID^Out_(3,2), pk′_Receiver, H³를 비밀 채널(secure-channel)을 통해 전달받은 후 거래를 생성한다. 이때, 송신자는 자신이 사용하는 UTXO의 소유권 증명값(zk-LTARK 영지식 증명 프로토콜 4.2.1 참고)과 자신의 신원을 오직 수신자만이 알 수 있도록 임의 개인키(d)로 EM^pk'Sender_(3,2)를 생성한다[3].

• 거래 검증 단계 : CB 및 CA는 송신자가 생성한 거래를 다음과 같은 과정으로 검증한다. 송신자의 pk_Sender가 CBDC 시스템에 사전에 등록된 값인지, 송신자가 생성한 거래의 입력값 코인의 합과 출력값 코인의 합이 일치하는지, 거래의 σ^CA_(3,1), σ^CA_(3,2) 값이 유효한지, 입력값 코인에 포함된 DDID^In_(3,1), DDID^In_(3,2)가 CBDC 네트워크에 이미 존재하는지(이중지불 여부 확인), 입력값에 포함된 송신자의 소유권 주장을 위한 r^zk_(3,j), sk_Sender ∙ Hⁱ의 유효성을 검증한다. 검증 과정을 통과한 거래는 CBDC 시스템 구성원 간의 합의(Consensus) 과정을 통해 원장에 기록된다[3].

• 거래 수신 단계 : 수신자는 자신이 송신자에게 전달한 DDID^Out_(3,2)값이 포함된 거래를 찾아, 거래 대금(출력값 코인)을 수령한다. 이때, 수신자는 거래에 공개된 임의 공개키(D)를 활용하여 송신자의 신원을 확인할 수 있다[3].

[3]은 4.1에서 제시한 CBDC가 프라이버시, 감사가능성, 투명성을 모두 보장 가능하다고 주장하지만, 본 논문은 [3]이 주장한 CBDC 시스템에서 개인키 추출 취약점이 존재함을 발견하였다.

4.2 개인키 추출 취약점

4.2.1 zk-LTARK 영지식 증명 프로토콜

거래에 포함된 입력값 코인의 소유권 증명은 송신자가 전달한 zk-LTARK값 (r^zk_(3,j), sk_Sender ∙ Hⁱ)을 CA가 검증하며 이루어진다.

r^zk_(3,j), sk_Sender ∙ Hⁱ은 두 개의 파라미터로 구성되며, 생성과정은 다음과 같다. 송신자는 모든 거래 파라미터 (T³)에 대한 해시값(c₃)을 계산한다. 송신자는 수식 (8)을 포함하여 r^zk_(3,j), sk_Sender ∙ Hⁱ을 생성하고, CA에게 전달한다. CA는 전달받은 c₃, H³, r^zk_(3,j), sk_Sender ∙ Hⁱ을 활용하여 수식 (9)를 통해 송신자의 입력값 코인의 소유권 주장을 검증한다.

T3 = [EMpk'Sender(3,2), H3, D, t3, Fee]       (6)

c₃ = SHA256 (T³)       (7)

r^zk_(3,j) = (sk'_Sender - c₃ · sk_Sender)       (8)

DDID^In_(3,j) = r^zk_(3,j) ∙ H³ + c₃ (sk_Sender ∙ Hⁱ)       (9)

[3]에서는 zk-LTARK 영지식 증명 프로토콜의 안전성에 대해 다음과 같이 주장한다. 공격자가 송신자의 sk_Sender와 sk'_Sender를 추출하기 위해서는 sk_Sender ∙ Hⁱ로부터 sk_Sender를 추출해야 한다. 이를 위해서 공격자는 이전 거래에 기록된 Hⁱ를 알아내고, 송신자의 sk_Sender를 찾아내야 한다. 그러나, sk_Sender ∙ Hⁱ로부터 sk_Sender를 계산하는 것은 타원곡선 이산대수 문제(Elliptic Curve Discrete Logarithm Problem; ECDLP)와 동일한 수준의 계산적 난이도(평균 1.5x10⁶⁴년 소요[3])를 가지므로 현실적으로 불가능하다고 주장한다.

하지만 [3]이 제안한 zk-LTARK 영지식 증명 프로토콜의 문제점은 DDID_u 생성과정에서 Hⁱ는 거래마다 랜덤하게 선택하지만, sk'_Sender는 고정이라는 점이다. [3]이 각 거래에 사용되는 DDID_u는 일회용이어야 한다고 명시하지만, 악의적인 CA는 아래와 같은 공격을 수행할 수 있다.

4.2.2 공격 시나리오

공격자의 공격 시나리오는 아래와 같이 수행 가능하다. 공격자는 송신자의 공개된 두 개의 거래 데이터로부터 〈(r^zk_(i,j), sk_Sender ∙ Hⁱ ), c_i, Hⁱ〉i∈{1,2}을 획득한다. 이후, 공격자는 아래 수식 (10-14)를 통해 송신자의 개인키 sk_Sender와 sk'_Sender를 모두 추출할 수 있다.

r^zk_(1,j) = sk'_Sender - c₁ ∙ sk_Sender mod q       (10)

r^zk_(2,j) = sk'_Sender - c₂ ∙ sk_Sender mod q       (11)

r^zk_(2,j) -r^zk_(1,j) = (c₁ - c₂)sk_Sender mod q       (12)

\(\begin{align}s k_{\text {Sender }}=\frac{r_{(2, j)}^{2 k}-r_{(1, j)}^{2 k}}{c_{1}-c_{2}}(\bmod q)\text { where }c_{1} \neq c_{2}\end{align}\)       (13)

sk'_Sender = r^zk_(3,j) + c₃ ∙ sk_Sender mod q       (14)

이는 [3]에서 주장한 ECDLP로의 환원(reduction)을 통해 증명한 시스템의 안전성 주장을 약화시킨다.

4.2.3 취약점의 영향

[3]이 제안한 zk-LTARK 영지식 증명 프로토콜은 송신자의 sk_Sender 와 sk'_Sender를 추출할 수 있다는 취약점 (4.2.2 공격 시나리오 참고)이 존재한다. [3]에서는 DDID^In_(3,j), H³, Amount^In_(3,j)가 거래의 공개 파라미터로 공개된다. 이는 공격자가 적극적인 행위 없이도 사용자의 프라이버시를 침해할 수 있게 하며, 구체적인 과정은 다음과 같다. 공격자는 거래의 입력값 코인의 DDID^In_(3,j) 를 출력값 코인의 DDID^Out_(i,j)로 가진 거래를 찾기 위해 원장을 활용한다. 공격자는 원장에서 공개된 거래 각각의 Hⁱ와 자신이 알고 있는 송신자의 sk_Sender를 활용하여 비교 (\(\begin{align}D D I D_{(i, j)}^{\text {Out }} \stackrel{?}{=} s k_{\text {Sender }} \cdot H^{i}\end{align}\)) 가능하다. 이러한 방식으로 공격자는 송신자가 생성한 모든 거래 내역을 정확하게 식별하고, 송신자가 생성한 각 거래를 연결(linkability)함으로써 송신자의 모든 거래이력 추적이 가능하다. 이러한 취약점은 CBDC 네트워크에 등록된 사용자의 프라이버시를 침해할 수 있으며, 공격자가 해당 취약점을 악용할 경우, 송신자가 보유한 UTXO에 대한 이중지불이나 송신자의 명의를 도용한 거래를 발생시킬 수 있다.

4.3 제안 시스템 Overview

본 장에서는 4.2에서 제기된 취약점에 대한 해결 방안을 제시한다. 이를 위해 제안 시스템에서는 사용자가 각 거래마다 sk'_u, pk'_u을 새롭게 생성 및 활용하는 구조로 시스템을 수정하였다(이에 따라 4.3부터 sk'_u, pk'_u는 임시 개인키-공개키 쌍이라 칭한다). 또한, 기존 [3]의 CBDC 시스템에서는 원장에 공개되는 금액에 의해 거래 간 연결성(linkability)이 성립하여 거래 시스템의 온전한 프라이버시를 보장할 수 없다는 한계점이 존재하였으므로, 본 논문의 제안 시스템에서는 거래에 포함되는 금액 정보를 페더슨 커밋먼트 형태(2.5 페더슨 커밋먼트 참고)로 포함하도록 설계하였다. 제안 시스템의 거래구조는 Fig. 2.와 같다.

Fig. 2. The construction of proposing transaction

제안 시스템에서는 생성된 거래로부터 CB 또는 거래 수신자가 검증 및 수신에 필요한 정보를 당사자만 획득할 수 있도록, 공개키 기반 암호(예: ElGamal[16])를 이용한 EM^rIn_(i,j) 를 활용한다.

4.3.1 시스템 가정

본 논문에서는 CB와 CA를 정직하지만 호기심이 많다(honest-but-curious)고 가정한다. CB는 송신자가 생성한 거래의 모든 파라미터를 검증하고, 그 중 공개될 경우 거래 간 연결성이 유출될 수 있는 정보를 삭제 및 수정 후, CBDC 네트워크에 브로드캐스트 한다. CA는 CB가 전달한 해당 거래를 검증하고, 검증 완료한 거래를 원장에 기록한다.

4.3.2 시스템 목표

• 프라이버시(Privacy) : 제안 시스템은 기존 [3]의 DDID_u를 활용하여 주요 프라이버시(sk_u, sk'_u, 신원(ID_u))를 보호하되, DDID_u와 Amount가 공개되지 않도록 하여, 제3자가 해당 값을 통해 거래 간 연결성을 알 수 있던 시스템 구조를 개선한다.

• 감사가능성(Auditability) : CB는 송신자가 생성한 거래가 제안 시스템의 감사정책 준수 여부를 감사 가능하다. 감사정책은 다음과 같다. 첫째, 송신자가 생성한 입력값 코인 총합과 출력값 코인 총합은 일치하여야 하며, 각각의 코인은 일정 범위 내에 있어야 한다. 둘째, 입력값 코인에 포함된 DDID^In_(i,j)는 이중지불되어서는 안 된다. 셋째, 송신자는 반드시 CBDC 네트워크에 사용자 등록이 되어있어야 하며, 올바른 과정을 통해 생성한 DDID^State_(i,j)를 사용하여야 한다. 넷째, 송신자는 자신의 UTXO만 사용 가능하다.

• 투명성(Transparency) : CBDC 네트워크에 참여중인 CB와 CA는 검증이 완료되어 원장에 기록된 거래의 모든 파라미터에 대하여 확인 가능하다.

4.4 세부 절차

본 논문 시스템의 세부 과정은 ‘사용자 등록’, ‘사전 준비’, ‘거래 생성’, ‘거래 검증’, ‘거래 수신‘ 총 다섯가지 단계를 통해 운영된다.

4.4.1 사용자 등록

사용자 등록 단계에서 Fig. 3.과 Fig. 4. 같이 사용자는 ID_u과 CBDC 네트워크에서 사용할 sk_u, pk_u를 생성 후, CA에게 자신의 ID_u과 pk_u를 전송한다. CA는 사용자로부터 수신받은 정보를 저장한다.

Fig. 3. Sequence diagram of user registration & long-term key generation

Fig. 4. User Registration

4.4.2 사전 준비

사전 준비 단계란 송신자가 신규 생성하는 거래의 출력값 코인에 포함할 DDID_u를 생성하고, CA로부터 검증을 받는 단계를 말한다. 제안하는 시스템에서 코인을 수신받기를 희망하는 사용자(수신자 또는 거래 잔액을 받는 송신자)는 거래를 생성하는 송신자에게 해당 거래에서 사용할 DDID_u를 전달해야 한다. 제안 시스템에서 임시 개인키-공개키(sk_u', pk_u')및 DDID_u를 생성하는 과정은 다음과 같다(세부절차 Fig. 5., Fig. 6. 참고).

Fig. 5. DDID Generation

Fig. 6. Sequence diagram of DDID generation

먼저, 제안 시스템은 임시 개인키-공개키 쌍 (sk_u', pk_u′)을 사용하기 위해 기존 [3]의 임의 공개키(Hⁱ)를 고정된 기저점(H)으로 변경하여 사용한다. 사용자는 sk_u', pk_u'을 생성한 후 DDID_u(=sk'_u ·H) 를 생성한다. 사용자는 해당 DDID_u의 유효성을 보장받기 위해, 자신은 사용자 등록을 진행하였고, sk_u, pk_u' 를 알고 있으며, DDID_u를 sk_u′ 로부터 올바르게 만들었음을 영지식 증명값(π^DDID_u)을 통해 CA에게 증명한다.

CA는 해당 영지식 증명을 검증 후, pk'_u와 DDID_u에 대한 σ^CA을 사용자에게 반환한다.

사용자의 영지식 증명은 아래 수식 (15)과 같은 관계를 만족한다.

• IKNOW {sk_u, sk'_u} SUCH THAT :

\(\begin{align}\left(\begin{array}{ll}p k_{u}=s k_{u} \cdot P & \wedge \\ p k_{u}^{\prime}=s k_{u}^{\prime} \cdot P & \wedge \\ D D I D_{u}=s k_{u}^{\prime} \cdot H & \end{array}\right)\end{align}\)       (15)

4.4.3 거래 생성

송신자가 생성하는 거래(TX) 구조는 Fig. 2.와 같으며, ‘입력값(I)’, ‘출력값(O)’, ‘거래 파라미터(Txparameters)’로 구성된다. 거래 생성은 수신자가 송신자에게 DDID_Receiver, pk'_Receiver를 전달하면서 시작된다(Fig. 7,, Fig. 8., Fig. 9. 참고).

Fig. 7. Sequence diagram of Transaction Generation (Before CB verify)

Fig. 8. Transaction Generation

Fig. 9. Sequence diagram of Transaction Generation (After CB verify)

송신자는 거래 I를 다음과 같은 절차를 통해 생성한다. 송신자는 이전 거래를 통해 본인이 소유한 코인에 포함된 DDID^Out_(i-1,j), I에 사용할 r^In_(i,j), pk'_Sender를 활용하여 Nullif_(i,j)를 생성한다. 그 다음, 송신자는 I에서 사용된 r^In_(i,j)를 활용하여 Com^Out_(i-1,j)를 재난수화 하고(=Com^In_(i,j)), 오직 CB만 확인 가능한 EM^rIn_(i,j)와 π^Ownership_(i,j)을 생성한 후, 자신의 pk'_Sender를 I에 포함시킨다(Fig. 8. line 2-7 참고). 송신자가 입력값 코인의 소유권 주장을 위해 생성하는 π^Ownership_(i,j)은 아래 수식 (16)과 같은 관계를 가진다.

• IKNOW {r^In_(i,j), sk'_Sender} SUCH THAT :

\(\begin{align}\left(\begin{array}{lr}p k_{\text {Sender }}^{\prime}=s k_{\text {Sender }}^{\prime} \cdot P & \wedge \\ \text { DDID }_{\text {Sender }}=s k_{\text {Sender }}^{\prime} \cdot H & \wedge \\ \text { Nullif }_{(i, j)}=\text { DDID }_{\text {Sender }}+r_{(i, j)}^{I n} \cdot U+p k_{\text {Sender }}^{\prime} \end{array}\right)\end{align}\)       (16)

거래의 O는 크게 수신자에게 송금할 UTXO(Fig. 2.의 Output1)와 자신이 반환 받을 UTXO(Fig. 2.의 Output2)으로 구성되며, 생성하는 과정은 다음과 같다(Fig. 8. line 8-12 참고) 먼저, 송신자는 수신자를 지칭하는 DDID^Out_(i,j)를 전달받고, 자신이 송금할 Amount^Out_(i,j)을 페더슨 커밋먼트 기법(2.5 페더슨 커밋먼트 참고)을 활용하여 Com^Out_(i,j)를 생성한다. 이때, 송신자는 거래 I의 Com^In_(i,j)의 총합과 O의 Com^Out_(i,j)의 총합이 일치하도록 하는 r^Out_(i,j)를 선택하여야 한다. 송신자의 난수선택 과정은 다음과 같다. 먼저, 생성해야 할 출력값 코인의 개수(J)보다 하나 더 적은 수의 코인의 개수 (J-1)에 대한 r^Out_(i,j)를 난수 생성기를 활용하여 선택한다. 이후, 마지막 하나의 r^Out_(i,J)에 대하여는 수식 (17)을 활용하여 생성한다. 각각의 난수는 F_p범위 내에서 선택되므로, 제3자가 각각의 Com^Out_(i,j)에 사용된 r^Out_(i,j)를 예측하기는 어렵다. r^In_(i,j)과 r^Out_(i,j)에서의 인덱스 j는 각각 입력값 코인과 출력값 코인의 개수를 의미한다.

\(\begin{align}r^{Out}_{(i,J)}:=(\sum_{i,j}r^{In}_{(i,j)}-\sum^{J-1}_{j=1}r^{Out}_{(i,j)})mod \ q\end{align}\)       (17)

또한, 송신자는 해당 Com^Out_(i,j)가 유효한 범위 내에 있음을 증명하기 위한 π^Range_(i,j)과Amount^Out_(i,j), Com^Out_(i,j)에서 사용했던 r^Out_(i,j)을 수신자에게 전달하기 위해 각각에 대한 EM^Amount_(i,j)와 EM^rOut_(i,j)를 생성한다. 이때, π^Range_(i,j)은 수식 (18)과 같은 관계를 가지며, 주요 절차는 다음과 같다. 먼저, 송신자는 Amount^Out_(i,j)을 수식 (19)와 같이 n개의 비트로 이루어진 벡터(a_L = (b_(i,j),0, b_(i,j).1, …, b_(i,j),n))로 분해한다 (여기서 n는 CBDC 시스템에서 허용하는 최대 금액을 나타내는 비트 길이이다.). 송신자는 각 비트(b_(i,j),k)가 0 또는 1이 되도록 하는 보조 비트 벡터 (a_R = a_L - 1_n)를 정의한다. 이후 송신자는 각 b_(i,j),k에 대해 새로운 블라인딩 값(r^Range_(i,j),k)를 생성한 후, 수식(20)을 활용하여 페더슨 커밋먼트를 구한다. 송신자 Fiat-Shamir 휴리스틱을 통해 생성된 챌린지값을 활용하여 수식 (19) 등의 조건들을 내적 (inner-product) 형태로 결합하고, 송신자는 이를 Bulletproofs 프로토콜에 따라 벡터를 재귀적으로 이진 분할하는 방식으로 증명하여 π^Range_(i,j)을 생성한다[10].

• IKNOW {Amount^Out_(i,j), r^Out_(i,j)} SUCH THAT :

\(\begin{align}\binom{\text{Com}_{(i, j)}^{\text {Out }}=\text{Amount}_{(i, j)}^{\text {Out }} \cdot Q+r_{(i, j)}^{\text {Out }} \cdot U \wedge}{ 0 \leq \text{Amount}_{(i, j)}^{\text {Out }}<2^{n} }\end{align}\)       (18)

\(\begin{align}Amount^{Out}_{(i,j)}=\sum^{n-1}_{k=0}2^k\cdot b_{(i,j),k}=<a_L,2^n>\end{align}\)        (19)

Com^Range_(i,j),k = b_(i,j),k · Q + r^Range_(i,j),k · U       (20)

마지막으로 송신자는 Fee를 생성한 거래에 첨부하고, 해당 TX_i를 CB에 전달한다.

CB는 송신자가 생성한 거래가 감사정책(4.3.2 시스템 목표의 감사정책 참고)을 준수하였는지 아래 다섯 가지 검증 절차를 수행한다(Fig. 8. line 15-21 참고). 첫째, CB는 거래 내 EM^rIn_(i,j)를 자신의 sk^Enc_CB로 복호화하여 r^In_(i,j)를 획득한다. 이를 활용하여 CB는 I의 Com^In_(i,j)의 총합과 O의 Com^Out_(i,j)의 총합이 일치함을 아래 수식 (21)를 통해 확인한다.

Com^In_(i,j) = Com^Out_(i,j) + Fee       (21)

둘째, CB는 각 O의 Com^Out_(i,j)가 시스템에서 허용하는 범위 값을 가졌는지 π^Range_(i,j)을 검증한다. 셋째, I에 포함된 Nullif_(i,j)로부터 DDID^Out_(i-1,j)를 계산하고, 해당 값이 실제 원장에 기재된 이전 거래내역에서 존재하는지 확인한다. 즉, 유효한 I를 사용한 거래인지 검증한다. 넷째, CB는 O에 포함된 DDID^Out_(i,j)와 이에 대응하는 CA의 σ^CA_(i,j)을 검증한다(Fig. 8. line 19 참고). 이를 통해 O에 포함된 DDID^Out_(i,j)의 유효성(사용자 신원)을 검증한다. 마지막으로, π^Ownership_(i,j)를 검증하여 거래에 포함된 I에 대해 송신자가 정당한 소유자가 맞는지 확인한다.

위 다섯 가지 감사 과정을 마친 CB는 송신자가 생성한 거래에서 Nullif_(i,j)와 Com^In_(i,j)를 활용하여 C_(i,j)와 σ^CB_(i,j)를 생성하여 I에 추가함으로써 해당 거래가 감사정책을 준수함을 기록한다. 또한, CB는 송신자의 프라이버시를 위해 pk'_Sender와 π^Ownership_(i,j)를 거래 파라미터에서 삭제한 후 CBDC 네트워크에 브로드캐스트 한다.

4.4.4 거래 검증

브로드캐스트를 통해 거래를 전달받은 CA들은 해당 거래를 원장에 기록하기 위한 합의(consensus)를 이루기 위해 총 네 가지의 검증 절차를 수행한다(세부절차 Fig. 10., Fig. 11. 참고). 먼저 CA는 CB와 동일하게 거래에 공개된 I의 Com^In_(i,j)의 총합과 O의 Com^Out_(i,j)의 일치 여부를 확인한다. 둘째, 출력값 코인에 포함된 π^Range_(i,j)을 검증하여, Com^Out_(i,j)에 포함된 Amount^Out_(i,j)이 유효한 범위 내 존재하는지 확인한다. 셋째, 거래에 포함된 CB의 C_(i,j)와 σ^CB_(i,j)의 유효성을 검증한다. 마지막으로 CA는 O에 포함된 DDID^Out_(i,j)와 이에 대응하는 CA의 서명 검증을 통해 출력값 코인 수신자의 유효성을 검증한다.

Fig. 10. Sequence diagram of Transaction Verification

Fig. 11. Transaction Verification

4.4.5 거래 수신

수신자는 DDID_u가 포함된 TX_i를 확인 후, 거래 정보를 수신한다. 수신자는 O의 EM^Amount_(i,j), EM^rOut_(i,j)를 자신의 sk^Enc_u를 활용하여 복호화함으로써 r^Out_(i,j)와 Amount^Out_(i,j)을 획득한다. 이후, Com^Out_(i,j)을 직접 계산하여 거래에 포함된 금액 커밋먼트값 과의 일치 여부를 확인한다(세부절차 Fig. 12., Fig. 13. 참고).

Fig. 12. Sequence diagram of Transaction Reception

Fig. 13. Transaction Reception

V. 시스템 분석

본 장에서는 제안하는 CBDC 시스템이 앞서 4.3.2에서 제시한 시스템 목표(프라이버시, 투명성, 감사가능성)를 모두 달성 가능함을 보임과 동시에, CB에 의한 능동적인(active) 감사활동이 수행 가능함을 설명한다. 또한, 전통적인 암호화폐 프로토콜 분석 도구를 통한 정형적 분석 결과에 관해 설명한다. 마지막으로, 실제 실행 성능을 확인하기 위해 거래 입력 개수와 거래 출력 개수에 따른 거래 생성 및 거래 검증 시간을 측정하고, 그 결과를 바탕으로 제안 기법의 실용성을 보인다.

5.1 보안 분석

본 논문 시스템의 공격 모델(attack model)은 거래 당사자 및 관여자(송신자, 수신자, CB, 사용자 등록을 담당한 CA)를 제외한 외부 공격자(external adversary)로부터의 공격과 거래 당사자 및 관여자에 의한 내부 공격자(internal adversary)로부터의 공격으로 구분할 수 있으며, 공격자는 시스템 사용자의 sk_u, sk'_u, sk^Enc_u등 타인이 수신한 출력값 코인을 소비하는 악의적인 거래 또는 이미 소비된 코인을 이중지불할 수 있는 거래를 생성하거나, 원장에 공개된 거래 정보를 바탕으로 각 거래간 연결정보를 파악하는 것을 목표로 하고 있다.

• 프라이버시(Privacy) : 본 논문의 CBDC 거래 시스템은 매 거래를 생성할 때마다 DDID_u를 새롭게 생성·활용하는 구조를 갖추고 있다. 따라서, 거래 당사자(송신자, 수신자)와 DDID_u 발급을 담당하는 CA 그리고 감사활동을 위해 연결 정보가 필요한 CB를 제외한 시스템 내 객체는해당 거래가 누구에게 코인을 송신하는지 알 수 없다. 또한, 제안하는 시스템에서는 Nullif_(i,j)를 활용하여 DDID^Out_(i,j)를 직접적으로 노출하지 않음으로써 누가 해당 거래를 발생시키는지 거래 주체의 정보를 숨길 수 있다. 마지막으로, 사용자가 생성·수신하는 Amount은 Com^Out_(i,j)로 숨겨져 있다. 따라서, 제안하는 시스템은 기본적으로 외부 공격자로부터 거래의 주요 프라이버시(신원 및 거래 금액)를 유지한 상태에서 유효한 거래를 생성하고, CB 및 CA로부터 생성한 거래를 검증받을 수 있는 구조를 갖추고 있다.

본 논문에서 제안하는 CBDC 시스템은 내부 공격자로부터도 거래의 프라이버시를 유지할 수 있다. 제안 시스템에서 거래를 수행하기 위해서는 CA로부터 DDID_u 사용을 승인받고, 수신자가 송신자에게 미리 DDID_u를 전달해야 거래를 생성할 수 있다. 따라서, CA 또는 해당 거래의 송신자는 수신자의 DDID_u를 알고 있기 때문에 수신자가 수신받은 거래를 추후 어떻게 활용하는지 연결정보를 파악하려 시도할 수 있으나, 제안 시스템의 거래 구조에서는 입력값 코인에 Nullif_(i,j) = DDID^Out_(i,j) + r^In_(i,j) · U + pk'_Sender를 활용하므로 r^In_(i,j)와 송신자의 pk'_Sender를 구할 수 없으므로, 해당 거래의 송신자는 수신자가 수신받은 코인을 어떻게 활용하는지 추적하는 등 연결정보를 확인하는 것은 불가능하다.

• 투명성(Transparency) : 본 논문의 CBDC 시스템은 컨소시엄 블록체인을 기반으로 동작한다. CBDC 시스템 내 CB 및 CA는 송신자가 생성한 거래 내용을 검증 후 원장에 기록하며, 최종 원장에 기록된 거래는 CBDC 시스템 참여자 모두 확인 및 검증 가능하다.

5.2 감사 가능성

본 논문에서 제안하는 CBDC 시스템의 감사정책은 크게 두 가지 기준에 따라 운영된다. 첫째, CB 및 CA에 의한 거래 검증 절차의 통과 여부, 둘째, 출력값 코인에 포함된 π^Range_(i,j)을 통한 송신 금액 한도 제한 정책의 준수 여부이다. 해당 정책을 미준수한 TX_i를 탐지한 CB는 거래 생성 및 검증 단계에서 CB가 보관 중인 각 거래 간 연결정보 (DDID^Out_(i-1,j) || Nullif^In_(i,j) 맵핑 정보)를 바탕으로 의심 거래와 연관된 거래를 선별할 수 있으며, 각 거래에 포함된 DDID^Out_(i,j)에 대해 서명(신원 검증)을 수행한 CA와 협조하여 사용자의 ID_u을 확인하고, 필요시 제재정책(블랙리스트 등재 또는 법적조치)을 적용할 수 있다.

5.3 정형적 분석

앞서 언급한 본 논문의 제안 시스템은 기존[3]의 보안 취약점에 대응 가능함을 수학적으로 증명하였다. 본 장에서는 제안하는 CBDC 시스템에 대해 실제 공격 가능 여부를 확인하기 위해 다음 보안 속성들에 대한 검증 모델을 제작하였다.

• 개인키 기밀성: 사용자의 개인키는 공격자에게 노출되어서는 안 된다.

• Amount 기밀성: Com^Out_(i,j)로부터 Amount은 복원하는 것이 계산적으로 불가능해야 한다.

• 난수(r) 기밀성: r는 공격자에게 노출되어서는 안 된다.

• 서명 위조 불가능성: CA 및 CB의 서명 위조는 불가능해야 한다.

Fig. 14.는 앞서 언급한 보안 속성들에 대한 ProVerif 분석 결과를 보여준다. 분석 결과, 개인키와 CA 및 CB의 서명은 “true”로, 공격자에게 노출되지 않으며, 안전성에 대한 보장이 증명되었다. Amount 및 r의 기밀성 보장 검증은 Scyther를 활용하여 분석을 수행하였다. Fig. 15.은 Scyther의 분석 결과를 보여준다. S는 Sender를 의미한다. Amount, r에 대해 “no attack withinbounds” 결과가 도출되었으며, 이는 본 논문에서 제안한 프로토콜이 Amount, r에 대해서도 기밀성을 보장함을 의미한다.

Fig. 14. ProVerif Verification Results

Fig. 15. Scyther Verification Results

5.4 연산 효율성

본 논문은 제안 시스템의 연산 효율성을 기존 관련 연구들과 비교 분석하였다. Table 3.은 각 연구에서 거래 생성 및 거래 검증 단계에서 사용되는 기법의 처리 과정에서 발생하는 연산을 세부 연산 단위로 분석한 결과를 보여준다. 이를 통해 제안 시스템의 연산량을 정량적으로 평가할 수 있으며, 우리가 연산 분석의 일관성을 위해 세운 기준은 다음과 같다. 첫째, 모든 기법의 연산 과정은 세부 연산 단위로 분해한다. 둘째, 각 거래는 입력 개수(N)과 출력 개수(M)을 기준으로 하여 연산 횟수를 계수한다. 셋째, 분석 대상 연산은 암호 연산으로 한정한다. 분석 대상 연산은 타원 곡선 곱셈(T_ECMul), 타원 곡선 덧셈(T_ECAdd), 유한체 곱셈 및 제곱(T_FMul), 유한체역원(T_FExp). 해시(T_Hash), 영지식 증명 생성(T_ZKGen), 영지식 증명 검증(T_ZKVer), 대칭키 암호 기법(T_Enc)의 연산이다. 분석 결과를 보면, 제안 시스템은 거래 생성 단계에서 영지식 증명을 생성하는 과정을 포함하므로, 거래 생성 시간이 증가할 수 있다. 그러나 우리는 [3]의 기존 시스템에서 발견된 개인키 추출 취약점과 거래 금액 및 연결 관계가 노출됨으로써 프라이버시를 보장하지 못한 점을 개선하였다.

Table 3. Comparative computational overhead of transaction generation and validation

5.5 성능 분석

본 논문은 제안 시스템의 실제 실행 성능을 평가하기 위해 실험을 진행하였다. 실험 환경은 Ubuntu 24.04 LTS 기반의 ARM64 가상 머신 환경에서 수행되었으며, Python 언어를 사용하여 거래 생성 및 거래 검증 과정을 구현하였다. 실험에서는 거래의 N와 M를 각각 1부터 10까지 변화시키며, 각 경우에 대해 실행 시간을 측정하였다. 실험 결과, 모든 N에 대해 거래 생성 및 거래 검증 시간은 M이 증가함에 따라 선형적으로 증가하는 경향을 보였다. 거래 생성 시간의 경우, N이 2일때 M이 1, 5, 10으로 증가함에 따라 각각 49.9 ms, 105.8ms, 174.4 ms로 측정되었다. N이 3일때는 동일한 조건에서 각각 68.5 ms, 123.9 ms, 192.5ms가 소요되었으며, N이 5인 경우에는 104.2ms,160.3 ms, 229.6 ms의 거래 생성 시간이 측정되었다(Fig. 16. 참조). 거래 검증 시간의 경우 N이 2이고 M이 1일 때 2.7ms가 소요되었으며, N이 1씩 증가할 때마다 약 0.9ms, M이 1씩 증가할 때마다 약 0.9ms씩 선형적으로 증가함을 확인하였다. 해당 결과는 [3]의 평균 거래 생성 및 거래 검증 시간이 각각 9ms 및 10ms와 절대적인 실행 시간 측면에서는 차이가 있으나, 기존 [3]이 갖고 있는 개인키 노출 취약점 및 거래 간 연결성 문제를 해결함과 동시에 N과 M의 증가에 따라 선형적으로 증가하는 예측 가능하고 효율적인 성능을 갖고 있음을 보여준다.

Fig. 16. Sender-side transaction generation time as a function of the number of input coins (N) and output coins (M).

VI. 결론

본 논문은 [3]의 CBDC 시스템에서 활용한 zk-LTARK 영지식 증명 프로토콜에 대한 보안 분석을 수행하고, 이를 통해 사용자의 개인키(또는 신원)가 노출될 수 있는 보안 취약점을 발견하였다. 또한, 발견한 보안 취약점을 해결하기 위해 sk'_Sender의 일회용 사용과 거래 금액을 페더슨 커밋먼트를 활용하여 숨기는 구조를 통해 CBDC 시스템에서 요구하는 프라이버시를 충족 가능한 새로운 CBDC 시스템을 제안하였다.

또한 Nullif_(i,j)를 거래구조에 추가 함으로써 거래 연결정보를 감사활동을 수행하는 CB를 제외한 제3자에게 노출하지 않으면서, 입력값 코인의 이중지불 여부를 감사 가능하도록 시스템을 설계하였다. 제안하는 CBDC 시스템에서는 감사활동을 수행하는 CB 외에는 각 거래 간 연결성을 알 수 없도록 설계하여 실제 CBDC 시스템 운용에 요구되는 적절한 감사가능성과 프라이버시의 균형을 맞추도록 설계하였다.

향후 이어지는 연구에서는 실험을 통한 성능 평가 및 다양한 공격 시나리오가 포함된 보안 분석을 통해, 제안하는 CBDC 시스템의 보안성과 실용성을 더욱 검증할 계획이며, 다양한 감사정책(사용자별 수신금액 한도설정 등)을 유연하게 적용 가능한 CBDC 시스템을 설계 및 제안할 계획이다.