ISTANBUL TECHNICAL UNIVERSITY ⋆ GRADUATE SCHOOL DESIGN AND ANALYSIS OF PRIVACY-PRESERVING AND REGULATIONS-COMPLIANT CENTRAL BANK DIGITAL CURRENCY M.Sc. THESIS Ali DOĞAN Applied Informatics Department Cybersecurity Engineering and Cryptography JULY 2024 ISTANBUL TECHNICAL UNIVERSITY ⋆ GRADUATE SCHOOL DESIGN AND ANALYSIS OF PRIVACY-PRESERVING AND REGULATIONS-COMPLIANT CENTRAL BANK DIGITAL CURRENCY M.Sc. THESIS Ali DOĞAN (707211012) Applied Informatics Department Cybersecurity Engineering and Cryptography Thesis Advisor: Prof. Dr. Kemal BIÇAKCI JULY 2024 İSTANBUL TEKNİK ÜNİVERSİTESİ ⋆ LİSANSÜSTÜ EĞİTİM ENSTİTÜSÜ MAHREMİYET KORUYUCU VE REGÜLASYONLARA UYUMLU MERKEZ BANKASI DİJİTAL PARASI TASARIMI VE ANALİZİ YÜKSEK LİSANS TEZİ Ali DOĞAN (707211012) Bilişim Uygulamaları Anabilim Dalı Bilgi Güvenliği Mühendisliği ve Kriptografi Programı Tez Danışmanı: Prof. Dr. Kemal BIÇAKCI TEMMUZ 2024 Ali DOĞAN, a M.Sc. student of ITU Graduate School student ID 707211012 success- fully defended the thesis entitled “DESIGN AND ANALYSIS OF PRIVACY-PRESERVING AND REGULATIONS-COMPLIANT CENTRAL BANK DIGITAL CURRENCY”, which he/she prepared after fulfilling the requirements specified in the associated leg- islations, before the jury whose signatures are below. Thesis Advisor : Prof. Dr. Kemal BIÇAKCI .............................. Istanbul Technical University Jury Members : Prof. Dr. Kemal BIÇAKCI .............................. Istanbul Technical University Prof. Dr. Enver ÖZDEMİR .............................. Istanbul Technical University Dr. Mustafa Utku KALAY .............................. Yıldız Technical University Date of Submission : 21 May 2024 Date of Defense : 12 July 2024 v vi To my family, vii viii FOREWORD First, I would like to express my gratitude to my supervisor, Prof. Dr. Kemal BIÇAKCI, for all of his guidance and support at every step throughout this study. He has welcomed all of my questions and provided insightful commentary. Second, I would like to express my special thanks to Dr. Taner DURSUN, my former manager at TÜBİTAK Blockchain Laboratory. He encouraged me to focus on state of the art problems and issues. Also, I thank all of his thoughtful understanding during this process. Additionaly, I am genuinely thankful to my fiancee, İrem ÇERE, for her unconditional love and support. This master thesis would not have been completed without her encouragement. Also, I would like to thank Mehmet Emre Yağar. He was with me from the first moment of my master’s process to the end. Last but not least, I would also like to express my deepest gratitude to my family. July 2024 Ali DOĞAN ix x TABLE OF CONTENTS Page FOREWORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix TABLE OF CONTENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii ABBREVIATIONS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii SYMBOLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix SUMMARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi ÖZET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxiii 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Pros of CBDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.1 Monetary sovereignty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.2 Financial Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.3 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.4 Programmable Money and Payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.5 Increasing in Seigniorage Income . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Cons of CBDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1 Lack of Regulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.2 Cyber Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.3 Operational Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.4 Offline Payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2.5 Privacy Preserving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3 Purpose of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.4 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.4.1 Platypus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.4.2 PEReDi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.4.3 Chaum-Style Blind-Signature System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.4.4 Cash-like Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.4.5 PRCash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.4.6 The Hamilton Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.4.7 Auditable Token Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.4.8 PARScoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2. CRYPTOGRAPHIC PRIMITIVES USED IN THE SYSTEM . . . . . . . . . . . . . . 19 2.1 Σ-Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1.1 Why Σ-Protocols was Chosen (zkSNARKs vs Σ-Protocols) . . . . . . . . . . . 21 2.1.2 Proof of Encryption Equality-1 (Σ-EE1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.1.3 Proof of 0 Encryption (Σ-E0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.1.4 Proof of Encryption-2 (Σ-EE2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.2 Bulletproof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.3 Fiat-Shamir Technique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.4 Distributed Key Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.5 Homomorphic Threshold ElGamal Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.5.1 Threshold Decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3. CONSTRUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.1 Security and Privacy Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2 Stakeholders & Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3 Balance Between Soft and Hard Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.4 Blockchain Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.5 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.5.1 System Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.5.2 User Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.5.3 Currency Issue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.5.4 Payment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 xi 3.5.5 Abort Transaction Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.5.6 Abort Transaction Privacy for Bank or Financial Institutions . . . . . . . . . 42 3.6 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.7 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4. SECURITY ANALYSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.1 Transaction Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.2 Transaction Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.3 Balance Adequacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.4 Negative Transaction Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.5 Regulation Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.6 Privacy Against Regulatory Agencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.7 Privacy Against Banks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.8 Banks and Users Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5. CONCLUSIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 CURRICULUM VITAE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 xii ABBREVIATIONS AML : Anti-Money-Laundering BIS : Bank for International Settlements CBDC : Central Bank Digital Currency CFT : Counter-Financial-Terrorism DKG : Distributed Key Generation ECB : European Central Bank ECDSA : Elliptic Curve Digital Signature Algorithm EdDSA : Edwards-curve Digital Signature Algorithm EUF-CMA : Existential Unforgeability under Chosen Message Attack IMF : International Monetary Fund KYC : Know-Your-Customer NIZK : Non-Interactive Zero Knowledge QAP : Quadratic Arithmetic Program SNARK : Succinct Non-interactive Argument of Knowledge UHS : Unspent Funds Hash Set UTXO : Unspent Transaction Output VRF : Verifiable Random Function ZKP : Zero Knowledge Proof xiii xiv SYMBOLS c : Challenge g : Generator of Group pk : Public Key sk : Secret Key t : Threshold w : Witness φ : ElGamal Encryption Σ-E0 : Proof of 0 Encryption Σ-EE1 : Proof of Encryption Equality-1 Σ-EE2 : Proof of Encryption Equality-2 xv xvi LIST OF TABLES Page Table 3.1 : Performance Evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 xvii xviii LIST OF FIGURES Page Figure 2.1 : Σ-Protocol for R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Figure 2.2 : Proof of Encryption Equality-1 (Σ-EE1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Figure 2.3 : Proof of 0 Encryption (Σ-E0). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Figure 2.4 : Proof of Encryption-2 (Σ-EE2).. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Figure 2.5 : Bulletproof Part1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Figure 2.6 : Bulletproof Part2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Figure 2.7 : Bulletproof Part3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Figure 3.1 : The System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 xix xx DESIGN AND ANALYSIS OF PRIVACY-PRESERVING AND REGULATIONS-COMPLIANT CENTRAL BANK DIGITAL CURRENCY SUMMARY Significant advances has been made in the field of Central Bank Digital Currency (CBDC) in the last five years. These advances are available not only in the academic world but also in central banks. Currently, more than 130 countries continue their CBDC studies at research, pilot and proof of concept levels. The increased interest in CBDC can be attributed to various factors such as the increasing progress in digital payment technologies, the widespread use of cryptocurrencies in the digital money market and the advantages brought by this technology. In addition to these advantages, there are challenges and problems that have not yet been resolved in order for CBDCs to reach the maturity level. One of these problems is the conflict between efforts to protect the privacy of digital currency users and the compliance mechanisms introduced by states to ensure financial stability and social order. States try to prevent and monitor financial crimes through regulations such as combating dirty money and preventing financing of terrorism. However, such regulations could lead to citizens’ lives being completely monitored in the transition to digital money. In addition to this conflict, a significant part of the existing CBDCs are operated on a blockchain-based system. Due to the transparent structure of the blockchain, parties included in the network can track and monitor users’ transactions, but transaction privacy is ignored. In the present study, solutions to the mentioned privacy problems are introduced with cryptographic techniques such as zero knowledge proofs, threshold cryptography, and homomorphic encryption. In the proposed system, the user’s balance is kept homomorphically encrypted in the blockchain. To perform a transfer transaction, the sender encrypts the amount he wants to transfer with his own public key, the receiver’s public key, and the regulators’ public key. The sender then creates a zero-knowledge proof that the amount is the same in all three ciphertexts. Since the transaction is processed through encrypted texts, the user must create a range proof that the balance he has is sufficient. After creating all the proofs and transmitting them to the blockchain, the nodes confirm the transaction and the user’s balance is homomorphically reduced via the ciphertext and the recipient’s balance is increased. In any suspicious case, the user’s transaction history can be traced back by government institutions called regulators. However, threshold encryption was used to ensure that this control was not left to the initiative of a single institution. These institutions must reach a consensus and after reaching the threshold value, they can see the transaction details. Additionally, techniques have been suggested so that commercial banks can continue their services in this system. xxi xxii MAHREMİYET KORUYUCU VE REGÜLASYONLARA UYUMLU MERKEZ BANKASI DİJİTAL PARASI TASARIMI VE ANALİZİ ÖZET Merkez Bankası Dijital Parası (MBDP), bir ülkenin merkez bankası tarafından basılan dijital formdaki resmi para birimi olarak tanımlanabilir. Geleneksel kağıt paranın yerine geçmeye aday olan bu finansal araç dünya genelinde büyük ilgi görüyor. Son beş yılda Merkez Bankası Dijital Parası çalışmalarında hem akademik dünyada hem de merkez bankaları bazında önemli ilerlemeler kaydedildi. Güncel olarak 130’dan fazla ülke MBDP çalışmalarına araştırma, pilot, kavram ispatı düzeylerinde devam ettirmektedir. MBDP’ye olan ilginin artması dijital ödeme teknolojilerinde artan ilerleme, dijital para piyasalarında kripto para birimlerinin yaygın kullanımı ve bu teknolojinin getirdiği hızlı ödemeler, fiziksel para basımı maliyetini ortadan kaldırması, programlanabilir ödemeler, finansal katılımı artırma, para politikalarının esnek şekilde uygulanabilmesi gibi çeşitli avantajlara bağlanabilir. Bu avantajların yanı sıra MBDP’lerin olgunluk düzeyine erişmesi için önünde çözümü henüz ortaya konulmamış zorluklar ve problemler var. Herhangi bir ağa ihtiyaç duymaksızın ödeme işleminin gerçekleştirilmesi olarak tanımlanan çevrim dışı ödeme, hızla ilerleyen teknolojiye karşılık veremeyen kanun ve yasalar, öngörülemez siber güvenlik riskleri, operasyonel riskler bu problem ve zorluklara örnek gösterilebilir. Bu teze konu olan problem ise dijital para kullanıcılarının mahremiyetini koruma çabaları ile devletlerin finansal istikrarı ve toplumsal düzeni sağlamak için getirdiği uyum mekanizmalarının çatışmasıdır. Devletler, kara para ile mücadele ve terörizme finansmanı önleme gibi düzenlemeler aracılığıyla finansal suçları önlemeye ve takip etmeye çalışmaktadır. Ancak, bu tür düzenlemeler dijital paraya geçişte vatandaşların hayatlarının tamamen izlenebilir olmasına neden olabilir. Bu çatışmanın yanı sıra mevcuttaki MBDP’lerin ciddi bir kısmı blokzincir tabanlı bir sistem üzerinde işletilmektedir. Blokzincirin şeffaf yapısı sebebiyle ağa dahil olan partiler kullanıcıların işlemlerini takip edebilme, ve izleyebilmekte olup işlem mahremiyeti göz ardı edilmektedir. Bu çalışmada sıfır bilgi ispatları, eşik kriptografi, homomorfik şifreleme gibi kriptografik teknikler ile bahsedilen mahremiyet problemlerine çözüm sunulmuştur. Kullanılan sıfır bilgi ispatlarının tamlık, doğruluk ve sıfır bilgi özelliklerini sağladığı gösterilmiştir. Kullanılan kriptografik algoritmaların performans sonuçları verilip, açık kaynak kodu paylaşılmıştır. Sistemin güvenlik analizi verilmiştir. Ayrıca literatürdeki aynı probleme çözüm sunan çalışmalar özetlenmiştir. Sistem, ilklendirme, kullanıcı kayıt, para itfa, ödeme, işlem mahremiyetini kaldırma ve finansal kurumlar için işlem mahremiyetini kaldırma protokollerinden oluşmaktadır. İlkendirme fazında merkez bankası, bankalar ve düzenleyici kurumlar için anahtar xxiii çifti üretilmektedir. Kullanıcı kayıt protokolünde kullanıcılar için şifreleme ve imza anahtar çiftleri üretilir ve blokzincirde işlem yapabilme yetkisi verilir. Para itfa protokolünde Merkez Bankası kullanıcılar veya finansal kurumlara para basar. Ödeme protokolünde kullanıcı başka bir kullanıcıya transfer işlemi gerçekleştirir. Mahremiyet kaldırma protokollerinde ise düzenleyici kurumların ve finansal kurumların görevlerini gerçekleştirebilmesi için ilgili kullanıcının geçmiş işlem bilgileri açığa çıkarılır. Önerilen sistemde kullanıcının bakiyesi, blokzincirde homomorfik şifrelenmiş olarak tutulur. Bir transfer işlemi gerçekleştirmek için, gönderici, transfer etmek istediği miktarı kendi açık anahtarı, alıcının açık anahtarı ve düzenleyici kurumların açık anahtarı ile şifreler. Daha sonra miktarın, üç şifreli metinde de aynı olduğuna dair bir sıfır bilgi ispatı oluşturur. İşlem şifreli metinler üzerinden işlediği için kullanıcının sahip olduğu bakiyenin yeterli olduğuna dair bir aralık kanıtı oluşturması gerekmektedir. Tüm kanıtları oluşturup blokzincire ilettikten sonra düğümler işlemi onaylar ve kullanıcının bakiyesi şifreli metin üzerinden homomorfik olarak düşürülüp alıcının bakiyesi artırılır. Herhangi bir şüpheli durumda kullanıcının işlem geçmişi regülator adını verdiğimiz düzenleyici kurumlar tarafından geriye dönük takip edilebilir. Fakat bu kontrolün, tek bir kurumun insiyatifine bırakılmaması için eşik şifreleme kullanılmıştır. Bu kurumlar bir fikir birliğine varmalı ve eşik değerine ulaştıktan sonra işlem detaylarını görebilmektedir.Eşik şifreleme için dağıtılmış anahtar üretimi kullanılmıştır. Düzenleyici kurumlar kurulum aşamasında bir araya gelerek herhangi bir güvenilir üçüncü tarafa ihtiyaç duymadan parçalı özel anahtarlarını oluşturur ve buna karşılık gelen açık anahtar oluşturulur. Anahtar üretimi sonunda hiçbir düzenleyici kurum açık anahtara karşılık gelen özel anahtara doğrudan erişime sahip olamaz. Ancak belirlenen eşik parametresine ulaşıldığı durumda içerik ulaşılabilir. İşlem içeriğini gizlemenin yanında, alıcı ve göndericinin kimliğini gizleme olanağı da bulunmaktadır. Bunu yapmak için gönderici belirlenen sayıda ek kullanıcı seçer. Alıcıya ve seçilen ek kullanıcıların her birine işlem gönderilir; yalnızca alıcıya gönderilen işlemin bir değeri vardır diğer işlemlerin değeri sıfırdır. Bu şekilde, tüm hesaplar homomorfik olarak güncellendiğinden ve yalnızca bir hesabın bakiyesinin değeri arttığından gerçek alıcının kim olduğunu gözlemlemek mümkün değildir. Ancak bu yöntem düzenleyici kurumların görevini zorlaştırmaktadır. Çoğu araştırma, kullanıcılar ve düzenleyici kurumlar arasındaki gizlilik anlaşmazlığını farklı teknikler ile ele alıyor, ancak önemli bir ayrıntıyı gözden kaçırıyorlar. Finansal sistemin önemli parçalarından biri de bankalar ve finansal kurumlardır. Bazı çalışmalar ise, mahremiyet gereksinimini göz ardı ederek bu kurumların MBDP sistemindeki rolünü detaylı olarak ele alıyor. Bu çalışmada, kullanıcı ile düzenleyici kurumlar arasındaki gizlilik anlaşmazlığına çözüm sunarken aynı zamanda kullanıcı ile bankalar arasındaki gizlilik anlaşmazlığına da çözüm getiriyoruz. Önerilen yöntem şifreli metinler üzerinden ilerlediği için bankalar kullanıcının onayı olmadan işlem hareketlerine kesinlikle ulaşamayacaktır. Kullanıcı özel anahtarını banka ile paylaşırsa mümkün olur. Fakat kullanıcının şifreleme özel anahtarını bankaya vermesi sadece geçmiş işlemlerini değil gelecek işlemleri için de şeffaflığa sebep olur. Bu sebeple önerdiğimiz protokolde banka ilk olarak bir kerelik bir açık anahtar oluşturur ve kullanıcıya iletir. Kullanıcı blokzincirden tüm geçmiş şifreli xxiv işlemlerini çeker, çözer ve bankanın ilettiği bir kerelik açık anahtar ile tekrardan şifreler. Daha sonra kullanıcı şifreli metinlerdeki değerlerini birbirlerine eşit olduğunu gösteren sıfır bilgi ispatlarını oluşturur ve bankaya şifreli metinler ile birlikte verir. Banka bu yöntem ile kullanıcının kendisini kandırmaya çalışmadığına ikna olur ve hizmetlerini kullanıcıya sunmaya devam eder. xxv xxvi 1. INTRODUCTION Central Bank Digital Currency (CBDC) is a digital form of currency created by a central bank and is considered a responsibility of that central bank. To put it simply, a person might view a CBDC as the digital counterpart of paper currency or physical cash issued by the central bank. There exist more detailed definitions in scholarly works. For example, CBDC is defined by Ward and Rochemont [1] as a digital representation of central bank currency that is different from typical reserve or settlement accounts. According to Bitter, CBDC is a publicly available, account-based, centrally issued, possibly interest-bearing digital liability of the central bank [2]. According to Kumhof and Noone, CBDC is electronic central bank currency that is easier to access than reserves, has better functionality for retail transactions than cash, and has a different organizational structure [3]. According to Kiff et al., a digital form that represents a sovereign currency issued by a central bank of a jurisdiction and is considered a liability is known as a CBDC [4]. Bordo and Levin [5], Engert and Fung [6], and Ozili [7] collectively define CBDC as electronically stored monetary value representing a central bank liability, usable for payments. In summary, these definitions highlight that a CBDC is a liability of the issuing central bank and differs from physical cash in its attributes, although it serves the same purpose. Significant progress has been made in the field of CBDC research over the last five years. The rise in interest in CBDC research can be ascribed to several factors, including the emergence of distributed ledger technologies powered by blockchain, the increasing progress in digital payment technologies, and the widespread use of cryptocurrencies in the digital currency market. While there are critics of CBDC asserting that its success may not align with promotional claims [8], supporters argue that CBDC offers significant positive benefits for both the economy and society. 1 1.1 Pros of CBDC In this section, the advantages of CBDC in the literature are summarized and its advantages are evaluated. Five main arguments in support of CBDC have been put forward by academics and public institutions of the financial sector. In the field of payments, central banks focus on preserving the integrity and validity of money. The goal is also to make transactions, particularly those involving cross-border payments, more efficient and cost-effective. 1.1.1 Monetary sovereignty Regulators and policymakers started to worry about the possible acceptance of digital assets as a means of payment as these assets gained prominence. Crypto assets have the potential to undermine the central bank’s authority over the monetary system if they are widely employed in the payment system [9]. Central banks may no longer be the main issuers of circulating money when an economy has an alternative to the official currency, which results in a loss of control over payment flows. This may lead to incomplete records and less control over the money supply, which would ultimately jeopardize the central bank’s capacity to carry out monetary policy. Because of this worry, China outlawed all crypto assets and created eYuan (China’s CBDC) [10]. This loss of influence could negatively impact the central bank’s capacity to manage aggregate demand, control inflation and inflation expectations, and ensure financial and macroeconomic stability. Even though the effects might not be felt immediately, central banks must prepare for and respond to changes in order to maintain financial stability. They must proactively address this by enacting the necessary laws and making innovative discoveries. The International Monetary Fund (IMF) specifically emphasizes that cryptocurrency assets should not be formally acknowledged as "legal tender" [11]. It also highlights how crucial it is for central banks to consciously "preserve monetary sovereignty." 2 1.1.2 Financial Inclusion Financial inclusion describes how well people and organizations are integrated into the financial system. This idea includes several components, including access to banking services, payment methods, tools for investing and saving, using these services, and taking part in financial decision-making. Providing for financial inclusion can have a favorable impact on a nation’s overall economic development, income disparity, poverty alleviation, and economic growth [12]. It has been demonstrated that Nigeria’s CBDC, eNaira, can enhance financial inclusion in various ways [13]. By providing features including a simple account opening process, access to digital financial services, affordable financial products, and the ability to avoid confusing bank fees and interest returns, eNaira removes the hurdles associated with traditional banking. It draws people who might have lost faith in traditional banks and promotes financial inclusion and systemic engagement. 1.1.3 Interoperability BIS defines interoperability as the technical or legal alignment that enables a system or mechanism to seamlessly operate in conjunction with other systems or mechanisms. This facilitates the ability of participants from diverse systems to transparently and securely conduct, clear, and settle payments or financial transactions across various systems, eliminating the need for involvement in multiple systems [14]. Lowering system and operational complexity will benefit users greatly and lower costs associated with cross-border transactions. For banks and other financial organizations, this results in lower execution costs. Project mBridge was started by the BIS Innovation Hub to guarantee interoperability in CBDCs [15]. Project mBridge is designed to enhance cross-border transactions by promoting the use of local currencies. It achieves this goal through the establishment of direct, bilateral connections between the payee’s and payer’s local banks, complemented by interoperability with participants’ domestic payment systems. This innovative approach results in quicker, more secure, and easily accessible cross-border payments, leading to a reduction in overall costs and settlement 3 risks. The facilitation of transactions in local currencies presents the potential for businesses and consumers to enjoy advantages such as decreased foreign exchange expenses, simplified payment processes, and heightened transparency in cross-border transactions. 1.1.4 Programmable Money and Payment Financial innovation is made possible by the digitization of central bank currency, allowing for programmable payments through the use of smart contracts with CBDC, ultimately reducing transaction friction. This innovation can result in increased efficiency and cost-effectiveness, leading to potential benefits for end users. As an illustration, the European Central Bank (ECB) envisions the possibility of conditional or programmable payments, where citizens can voluntarily establish predetermined conditions for automated payments and deductions, such as rent or utility bills, facilitated by the use of CBDC [16]. Programmable money and programmable payments are two different things, according to the ECB [17]. Programmable money involves setting conditions on the digital Euro, such as specifying expiry dates on stimulus funds, imposing spending restrictions to certain localities or regions, or dictating expenditures exclusively on particular items like food. Programmable payments, on the other hand, refer to the capability to automatically initiate payments when predefined conditions are satisfied. In essence, CBDC serves as a digital currency in e-wallets for settlements, and programmable payments dictate the actions possible with CBDC in e-wallets. 1.1.5 Increasing in Seigniorage Income CBDCs stand out due to their cost-effectiveness in creating currency, providing a clear edge over traditional paper notes and coins. Conventional physical currency is made through several complex, costly, and time-consuming processes, including printing, security checks, and logistical activities. Conversely, because CBDCs are digital, the production process is streamlined, significantly reducing costs. Central banks can produce currency more quickly and cheaply by issuing and distributing CBDCs 4 electronically. This advantage facilitates more efficient management of liquidity and money supply within the financial system. Central Bank of the Republic of Türkiye stated that the average unit cost of banknotes completed in 2020 was approximately 0.26 Turkish Lira (26 Kurus). Factors influencing banknote costs include input expenses, production quantities, and printing specifications [18]. In 2022, the Federal Reserve reported variable printing costs for specific currency denominations. The printing costs for various notes in 2022 range from 2.8 cents for $1 to 8.6 cents for $100 [19]. 1.2 Cons of CBDC This section states the arguments and challenges against CBDCs. In addition to the discussions, the solutions to the privacy problem are also explained in detail in the relevant study section, since they are within the scope of this thesis. 1.2.1 Lack of Regulation Regulation plays a crucial role in overseeing the payments system, ensuring competition, and promoting efficient operations. It is also essential for creating an environment that encourages the adoption of the latest technology and fosters innovation. Policymakers rely on regulation as a tool to achieve these goals. However, with technology evolving so quickly, choosing the appropriate level of control is becoming increasingly difficult. It can be challenging for regulators to keep up with technology developments, which makes it challenging to create suitable regulations. They run the risk of slipping behind even with their best attempts at adaptability. Finding the correct balance is essential because too lax laws can jeopardize financial stability, while too strict ones might stifle innovation and reduce advances in societal efficiency [4]. With the growing trend of digital transactions, central banks must actively seek methods to maintain the significance of central bank money within the payments system. This is crucial for solidifying trust and credibility in central bank money. 5 Failing to do so would result in a decline in public trust in commercial bank money as well as central bank money, which might be dangerous for social and financial stability. 1.2.2 Cyber Security In the case of CBDC, Auer et al. [20] point out that cybersecurity risk is a critical consideration for central banks [20]. Although there are no systemic concerns to the national financial system from potential dangers associated with private crypto assets, safeguarding consumers from them presents a substantial problem. With its direct central bank authority, CBDC is viewed as a way to reduce the risks that come with innovations in the private sector by providing protections against things like asset security problems, fraudulent transactions, and leaks of private data. However, it’s acknowledged that CBDC is susceptible to cybersecurity issues. This introduces the possibility of risks to the entire financial system, as any disruption in the CBDC system could impact wholesale and retail payment infrastructures. Such disruptions may lead to financial shocks, including severe liquidity shortages or defaults by commercial banks. The potential for system-wide outages raises concerns about financial stability, making central banks particularly wary of the systemic risks associated with the implementation of CBDC [21]. 1.2.3 Operational Risks Controlling operational risks during CBDC implementation is a significant and complex task that should not be disregarded. With the inherent uncertainties associated with introducing new technology, perfect operation cannot be guaranteed, even with extensive planning. To ensure the system’s robustness, pilot runs are essential for stress testing it before it is put into use. To further improve the system’s resilience, procedures such as creating efficient backup plans for unforeseen catastrophes must be set up. These strategies may include keeping ongoing database backups, although there are expenses involved and possible tradeoffs in efficiency with this strategy. 6 1.2.4 Offline Payment Offline payment is one of the most important problems on the way to the integration of CBDCs into real life. When using cash in daily life, we can shop without being connected to any server. Concretely, a person can take cash out of his wallet and do his shopping without being connected to any server or network. In the future, when the use of cash is eliminated, we will need offline payment solutions in a world where CBDCs come into our lives. There is global consensus that offline payment should be a feature that should be included in CBDCs. The European Central Bank emphasizes the need for a digital euro to include offline payment functionality in order to align with the key characteristics of physical cash, aiming to address the declining acceptance of cash [22]. Similarly, the Bank of England highlights the vulnerability of a CBDC to large-scale outages of electricity and data networks unless an offline payments feature is developed. Additionally, the CBDC would only be a valuable contingency measure if, during any outage, individuals already held CBDC, were familiar with making CBDC payments, and if CBDC was widely accepted by merchants [23]. The Federal Reserve acknowledges that a CBDC could improve the operational resilience of the payment system if it incorporates offline capability [24]. It’s essential to note that all three central banks underscore the importance of ensuring that offline payments do not compromise the security of the system and are effective in preventing double spending. We divide offline payment solutions in the literature (not just CBDC) into two. These are detectable solutions and preventable solutions. Preventable solutions [25], [26] [27], [28] focus on identifying the attacker who carried out the attack after double spending is detected. Although it is possible to prevent such attacks with deterrent penalties, an attacker who double-spends large amounts will reduce trust in CBDC. On the other hand, detectable solutions [29], [30], [31], [32] are solutions aimed at instantaneous double spending prevention. The only way to secure offline payments is to use a secure element such as a Trusted Execution Environment (TEE), smart card, SIM card or eSIM. Since there is no network connection available, there is no third 7 party available to verify the transaction, and therefore the payee needs inimitable proof that the payer verified the transaction and has the necessary funds for the transaction. 1.2.5 Privacy Preserving In the study conducted by Abramova et al., Austrian residents were asked some questions about their views on CBDCs and inferences were made from these answers [33]. Some of the questions asked in this study are security, privacy about personal data, ease of payment, usability in internet payments. Almost 70 percent stated that the protection of personal data is very important to them. In a report by the Swiss National Bank [34], "mass surveillance" is specifically identified as a potential risk associated with a CBDC. This underscores the importance of ensuring strong privacy protections. Furthermore, a survey conducted by the European Central Bank [35] revealed that privacy was considered the most critical aspect of a CBDC. There is a suggestion that conflict between privacy and regulatory requirements can be resolved by allowing anonymous payments up to a specific limit per unit of time [36]. Previous works have proposed this idea [37], [38], [39]. The idea does not meet the requirements. Government officials may not mind evading a $100 tax, but when it comes to a criminal or murderer, payment information is critical. Various suggestions for solving this conflict are summarized in the related work section. These solutions include various cryptographic techniques such as zero-knowledge proof, commitment scheme, threshold cryptography, and blind signature. While most studies discuss the privacy issue between users and regulatory authorities, they leave out an important component. Banks and financial institutions are critical components of a financial system. Some studies disregard the need for privacy and incorporate these institutions in the CBDC system; however, no system presently exists that provides a solution to the privacy issue between banks, financial institutions, and users. Although Solidus [40] is designed as bank-intermediated system by including banks, it cannot be said to provide full privacy between the user and the bank. In addition, it is not a decentralized design since the continuity of transactions depends 8 on the bank. In [41], the authors stated that these solutions do not explicitly address the privacy conflict between stakeholder groups (merchants, banks and payment providers, government). In the article, Auer et al. mentioned not only the privacy conflict between the user and the government but also the high level of conflict between other groups. They have also divided the situations in which the user’s data should be accessed and the stakeholder who wants to access it, layer by layer. 1.3 Purpose of Thesis While CBDCs are expected to provide a critical feature privacy, CBDCs must accommodate some regulatory requirements for financial stability and government security. Regulatory requirements for CBDCs are the enforcement of anti-money- laundering (AML), know-your-customer (KYC), and counter-financial-terrorism (CFT) [42]. On the other hand, this contradicts the objective of enhancing payment privacy. Most studies cover the privacy issue between users and authorities, but they leave out an important component. Banks and financial institutions are critical components of a financial system. Some studies disregard the need for privacy and incorporate these institutions in the CBDC system; however, no system presently exists that provides a solution to the privacy issue between banks, financial institutions, and users. In this study, we present a solution to the privacy dispute between the user and the authorities, as well as a solution to the privacy conflict between the user and the banks. Based on the motivation to provide both the privacy of users and regulatory requirements and the idea of bringing other stakeholders (merchants, banks and payment providers) into the system, our first aim is to design a system in which a person suspected by the regulatory agencies can track all transactions retrospectively. Our second goal is to include banks and companies that use financial data in the system and to solve the privacy conflict between them and the user. 1.4 Literature Review 1.4.1 Platypus 9 In the Platypus [43], the benefits of traditional e-cash-like [44] systems and blockchain-based solutions were combined and the relevant report tried to provide the features expected from a CBDC. In the system,a central bank defines as the authority to ensure the reliability of the currency and to prevent double spending; the central bank is not trusted regarding the confidentiality in the system. Zero knowledge proofs methods are used to ensure the privacy of the amount of money transfer, and performance results of the implementation using zk-SNARK structures are given by the designers. Platypus ensures the privacy of money transfers, each user has his own account status (stateA i ), and after each transaction in which he is a receiver or sender, the account status is updated and a new account status (stateA i+1) is created. Each user has a signature value (σA i ) added to the account status with the Central Bank’s private key, indicating that the current account status has a balance created after a money transfer approved by the central bank. Sender sends the amount of money it wants to transfer, the commitment to deduct this expenditure from its current balance, and the serial number indicating that this expenditure is made for the first time, together with the relevant zero-knowledge proofs, to the recipient. The recipient updates their account status with the amount of money transfer they received. It sends the commitments from the sender, serial number and zero-knowledge proof to the central bank along with the relevant commitments and parameters prepared by itself. In order to prevent double spending, serial numbers generated randomly by users are used in money transfers and commitments conveyed in these transfers. Under the assumption that the commitment schemes used in the model are computationally binding and custodial and that the signatures are inimitable; the central bank can approve this money transfer by verifying that there is no double spending and zero-knowledge proofs. The updated account statuses of the receiver and the sender are signed by the central bank to confirm that this transfer has been approved. These signature values are sent to the buyer and the payment is accepted by the buyer. The Platypus payment system also has an authorized regulatory authority defined in order to prevent risky transactions that may threaten financial stability. It has been shown that policies that can be expected to be adhered to by the regulator in the financial system, such as the maximum amount of balance that can be held in the 10 account, the maximum amount of money transfers that can be received / sent within a certain period of time, can be achieved by the Platypus payment system. 1.4.2 PEReDi PEReDi [45] is the first CBDC proposal that both prioritizes privacy and adds the necessary structures for the aforementioned financial regulators to its model. PS Signature [46] was used for Threshold-Issuance Anonymous Credential in the model. There are three parties in the model: the central bank, intermediaries (commercial banks, financial institutions) and users. The main task of the central bank is to issue digital currency and manage monetary policy. The central bank does not have the ability to access the recipient, sender and amount information of the transactions. Additionally, the central bank is not responsible for enforcing regulatory rules. Maintainers are responsible for constantly updating the system as users post transactions. Basic features such as system integrity, compliance, and confidentiality of transactions are provided by intermediaries. Finally, the registration process of users is the responsibility of the intermediary institutions and the registration phase is subject to the approval of the intermediaries. Each maintainer manages encrypted ledger in PEReDi; transactions are identifiable by transaction identifiers and leave encrypted traces in the ledger. If there is enough proof of suspicious activity by a certain person or transaction, the tracking and deprivation features (Tracing and Opening) can be used. With these functions, transactions made by that user can be monitored or the identities of the parties can be revealed. Due to the threshold encryption method used, the approval of a certain number of agents is required to run the monitoring and privacy removal functions. This brings a control mechanism to the model. If the t threshold is reached, the user’s transactions can be tracked. In the payment protocol, the sender and receiver must be online. The sender creates two ElGamal ciphertexts. In one, it encrypts its own public key and amount, and in the second, it encrypts the public key of the recipient. The sender updates his account information and proves with zero-knowledge proofs that he knows the blinded secret 11 key corresponding to the public key, that it does not exceed the specified maximum amounts, that he has sufficient funds in his account, and that he knows the random values he used. The sender also updates his account information in the same way, and the sender proves with zero-knowledge proofs that he knows the blinded secret key corresponding to the public key, that it does not exceed the specified maximum amounts, and that he knows the random values he uses. The sender and receiver send the ciphertexts and blinded values to the maintainers, and this transaction is recorded in the ledger. Maintainers blindly sign the values of the receiver and sender and send them back, and the parties turn them into a single signature and the transaction is completed. 1.4.3 Chaum-Style Blind-Signature System Chaum et al propose the adoption of a token-based approach with an embedded expiration date and a blind-signature scheme [25]. The key innovation outlined in the paper revolves around achieving perfect transaction privacy that is resilient to quantum attacks, all while adhering to Anti-Money Laundering (AML) and Countering the Financing of Terrorism (CFT) regulations. The inclusion of blind signatures in this system produces many noteworthy results. First, it introduces a layer of user anonymity that imposes compliance responsibilities on commercial banks, similar to traditional monetary systems where transactions are routed through these institutions. A distinctive advantage of this system compared to traditional paper currency is the revenue transparency inherent in the transaction processes. This transparency not only ensures a positive outcome, but also adds to the complexity of tax evasion, making it more challenging. Second, since the system is primarily based on key exchange protocols, the hardware complexity required is quite low, given that the computational demands of the process are not particularly high. The role of the central bank in this system is characterized by relatively simple responsibilities. From the signer’s perspective, blind signatures work similarly to regular digital signatures. Therefore, traditional data center practices regarding availability, reliability and scalability can be seamlessly applied to this system, potentially achieving high throughput. As a result, the overall cost of implementing and maintaining the system for both the central bank and commercial 12 banks is expected to be comparable to modern real-time gross settlement systems already prevalent in the banking industry. The recommended method to prevent double spending involves the recipient depositing the money with the central bank after a transaction. The central bank then verifies whether the coin has already been spent. However, from the reciver’s perspective, it falls short of protecting against double spending, especially in cases of prolonged offline periods. 1.4.4 Cash-like Privacy Transaction limits and conversion limits apply to completely private transactions. These limits are designed to be compatible with existing regulatory frameworks and meet AML and CFT requirements. Additionally, flexibility of limits is important to adapt to future regulatory changes. The system offers three different payment types: fully private, semi-private and fully transparent. Completely private payments ensure that transaction data remains completely private. These payments are carried out in private accounts and transaction data is shared only between the transaction parties. These transactions are verified using ZKPs and transaction limits and conversion limits are applied. Semi-private payments ensure that transaction data remains partially private. These payments are made from transparent accounts to private accounts or from private accounts to transparent accounts. These transactions maintain the privacy of transaction data, except for the transaction amount shared between transaction parties. Fully transparent payments are payments where transaction data is completely open. These payments are made from transparent accounts and transaction data is visible to everyone. The CBDC system protects the confidentiality of transaction data by using ZKPs for fully private payments. In this way, users can protect their privacy while performing their transactions. 1.4.5 PRCash 13 In many countries, citizens are required to report large financial transactions. Based on this restriction, the authors designed a system that restricts the anonymous payments amount that can be made within a certain period of time [47]. By setting the amount and duration, authorities are able to check the capacity of anonymous money, for example, allowing anonymous payments of up to 5,000 units within 1 month. With small design changes, spending can be limited instead of buying. Payments consist of inputs and outputs that use commitment schemes to hide the sender, receiver and transferred amounts. For output commits, blind factors are chosen so that the sum of input commits equals the sum of output commits. This permits verifying the accuracy of a transaction without knowledge of the value transferred. One of the outputs is a special output to which no value is added or spent. This allows the new owner of the transferred amount, that is, the recipient, to create new transactions without knowing the blinding factor. To ensure regulations on transactions, the user has two options for each payment. First, if the user wants the transaction to remain anonymous, he must prove that he has not exceeded the v limit without revealing his identity. Secondly, if the user wants to exceed the anonymity limit in the transaction, he must link his identity to the transaction, encrypted with the issuer’s public key. A user calculates a pseudorandom ID (PID) for each period he links to the outputs. It also adds a ZKP that the ID was calculated correctly and a range proof over the sum of all process outputs from that PID. The values are sent to validators along with transaction outputs. Proofs are checked by validators. If a transaction fails validation (for example, when Alice or Bob tries to make a transaction that exceeds the allowable anonymity limit, the transaction inputs and outputs are inconsistent, or one of the proofs is invalid), the transaction is refused. If the transaction includes any non-anonymous output, validators first validate its authenticity before passing the encrypted ID to the issuer, which can disclose Alice’s or Bob’s identity depending on which transaction output was anonymized. 1.4.6 The Hamilton Project The Hamilton Project is published by the Massachusetts Institute of Technology [48]. It uses Unspent Transaction Output (UTXO) . 14 The Hamilton project uses existing Unspent Transaction Outputs (UTXOs) in the transaction process and generates new UTXOs so that the total value of the new outputs matches the value of those spent. In order for a transaction to occur, the receiver gives his public key to the sender. The sender then creates the transaction, including the UTXOs spent, determines the value of each new UTXO, and specifies the associated obligations. Each UTXO spent is signed with the corresponding private key. These signatures are included in the transaction to finalize the transaction. The completed transaction is shared with all relevant parties, including all relevant details, before being submitted to the central bank. It verifies the correctness of the central bank syntax, ensures equality of input UTXO values and requested output UTXO values, and verifies that each spent UTXO signature matches the provided private key. If the transaction is valid, serial numbers are assigned to each UTXO output and a hash is then applied to all UTXOs. The central bank keeps track of all unspent UTXOs using a hash set called the Unspent Funds Hash Set (UHS). In this system, the central bank checks whether the spent UTXOs are within the UHS. Once the verification process is accomplished, old UTXOs are removed from the UHS and new output UTXOs are added. Only the central bank has access to the UHS. Thanks to UHS where hashes are stored, users are provided with a certain level of privacy. However, identifying information in the transaction exists in the form of public keys, so the government or central bank can track user and spending data before the UTXOs are hashed. 1.4.7 Auditable Token Payments An auditable, anonymous, token-based system for usage on a permissioned blockchain has been proposed by Androulaki et al. [49]. Their system employs a UTXO , in which UTXOs are represented as Pedersen commitments, in contrast to account-based approaches. Transactions are registered on the blockchain and the newly produced UTXOs are signed by the validator using the randomizable signature once the spender demonstrates that they have a signature on each UTXO spent. Furthermore, the system allows auditors, each of whom is in charge of supervising a distinct group of participants, to access all information pertaining to the participants assigned to them. 15 The system resembles a modified Zcash, with pre-designated administrators who append more signatures to transactions when the maximum value is reached. Since the system is UTXO-based and anonymous, a transfer transaction includes input and output tokens. In the system, it is necessary to verify that the sender is the real owner of the input token, that the owner of the output token is registered in the system, that the type and value of the token is protected, and that the input token has not been spent before (double spending is prevented). The proposed system provides auditing using encryption-based auditability and signature-based membership proofs while protecting user privacy. Transactions contain ciphertexts intended for authorized auditors, and ZKPs are calculated by the user of the transaction to link the ciphertexts to the transaction circumstances and confirm that the information is correct. Additionally, signatures are used to prove that a user is registered and to implement zero-knowledge membership proofs to prove that a token is a valid tokens recorded on the ledger. The combination of these techniques allows auditors to see all transaction information regarding a particular user and at the same time maintain the confidentiality of transaction content. 1.4.8 PARScoin Although PARScoin [50] is not designed as a CBDC, it was included in the literature review due to its regulation-friendly and privacy preserving features. PARScoin is a stablecoin design that addresses the conflict of privacy and regulation. It was designed inspired by PEReDi’s account structure [45], however unlike PEReDi, it eliminates the need for the sender and receiver to be online for the transaction to occur. The entity the authors describe as "the custodian" is similar to the central bank in a CBDC. The custodian is tasked with the dual purpose of protecting these stablecoins and ensuring their liquidity. Another entity is "issuers". Issuers’ responsibilities are to register users, approve transactions (verify ZKPs, etc.), and ensure compliance with regulation. The responsibilities of issuers can also be compared to the responsibilities of banks in a CBDC system. The other entity’s task, introduced as "the auditor", is to provide the auditing mechanism. 16 Since PARScoin consists of discrete logarithm-based algorithms, it uses Σ-protocols instead of zk-SNARKs. The system consists of five main protocols: User registration, stablecoin issuance, stablecoin transfer, stablecoin claim, stablecoin burn and reserve audit. User registration and stablecoin transfer that may be useful for CBDCs are summarized below. The user creates the user account (consists of an account balance, private key, public key and a random value) in the registration protocol. A modified version of Coconut [51] was used in the protocol. Since Coconut (selective disclosure credential) is a threshold blind signature, the user must create a proof that his balance is 0 and other proofs (related to commitment values). After preparing the proofs, it follows the registration protocol. After the proofs are verified, the user finishes the protocol by combining the incoming partial signatures. In the transfer protocol, the sender creates ciphertexts for himself and the receiver with ElGamal Encyrption public keys. To update the credential, it blinds the attributes in the account and creates the proofs, similar to the registration protocol. The proofs are then verified and the signature pieces are sent to the sender. The sender updates his account by combining signatures. 17 18 2. CRYPTOGRAPHIC PRIMITIVES USED IN THE SYSTEM In this chapter, the cryptographic primitives used in the system are introduced. Firstly, the definition of Σ-Protocols is given and the proof of the compliance of the Σ-Protocols used with the definition is given. Next, Bulletproof used for range proof is explained. Then, Distributed Key Generation, Threshold ElGamal Encryption, which does not leave the system dependent on a single authority, is given. Finally, homomorphic encryption is mentioned. 2.1 Σ-Protocols Σ-Protocols, are cryptographic techniques that allow a prover to convince a verifier that they possess knowledge of a value x satisfying a specific relation, all without showing any additional information about x [52]. Σ-Protocols find utility in the development of various cryptographic applications, credential protocols, e-voting protocols and group/ring signatures. In the proposed system, they were used to ensure privacy. One commonly known example of Σ-Protocols is Schnorr’s protocol [53], designed for demonstrating knowledge of a discrete logarithm. The concept of Σ-Protocols generalizes not only Schnorr’s protocol but also the identification protocols of Guillou-Quisquater [54] and Okamoto [55], along with numerous other protocols known in the literature. More formally, consider a binary relation R = (v;w)⊆V ×W , where v ∈V represents the shared input for both the prover and the verifier, and w ∈W represents a witness, serving as the prover’s private input. The language L = {v ∈V : ∃w ∈W (v; w) ∈ R} is defined as the set of inputs v in V for which there exists a witness w in W such that (v; w) ∈ R [56]. These proof systems possess three essential properties. First, completeness is that if the verifier and prover follow the protocol correctly, the verifier will accept the proof. Second, for any x and a pair of accepting conversations on input x represented as 19 Prover P Verifier V ((v, w) ∈ R) (v ∈V ) a← α(v, w, uP) announcement a−−−−−−−−−−−→ c ∈R C challenge c←−−−−−−−−−−− r← ρ(v, w, c, uP) response r−−−−−−−−−−−→ Φ(v, a, c, r)? Accept the conversation (a, c, r) if the condition Φ(v, a, c, r) is satisfied. Figure 2.1 : Σ-Protocol for R. (a,c,z) and (a,c′,z′) with e ̸= e′ there exists an efficient method to compute w such that (x,w) ∈ R. This is called the special soundness. Third, special honest-verifier zero knowledge (SHVZK) asserts that expressed through the existence of a specialized simulator known as the SHVZK simulator. Given a statement x and a challenge c, the simulator outputs (a,z) in a manner such that (a,c,z) forms an accepting 3-message transcript for x and is indistinguishable from a transcript produced by an honest prover when the challenge is c. Its definition is given below. A Σ-Protocol for a relation R is a communication protocol involving a prover P and a verifier V , outlined in Figure 2.1, and adhering to the following three principles: • Completeness: If both the prover P and verifier V adhere to the protocol, V always accepts. • Special Soundness: There exists an efficient probabilistic polynomial time algorithm E (extractor) that, given any verifier output v and two accepting conversations (a; c; r) and (a; c; r) where c ̸= c, can compute a witness w such that (v; w) ∈ R. • Special Honest-Verifier Zero-Knowledgeness: There exists an efficient algorithm S (simulator) that, given any verifier output v in the language L and any challenge c, generates conversations (a; c; r) with the same probability distribution as conversations between an honest prover P and verifier V for the given input v and challenge c. 20 2.1.1 Why Σ-Protocols was Chosen (zkSNARKs vs Σ-Protocols) Non Interactive Zero Knowledge (NIZK) proofs can be divided into two main categories: zk-SNARKs and Σ-Protocols with Fiat-Shamir. Both approaches have different efficiency characteristics, advantages and disadvantages. However, each has different characteristics in terms of factors such as computational cost, security level and overall complexity. This variety allows users to choose one that suits their specific application needs. Zk-SNARKs can be theoretically applied to prove algebraic expressions, for example they can represent the circuit via Quadratic Arithmetic Programs (QAPs) [57]. However, the circuit for calculating a single exponential number in a group G usually consists of thousands of gates. QAP-based zk-SNARKs increase the computational cost of the prover linearly with the size of the circuit and require the creation of a reliable common reference sequence. For this reason, zk-SNARKs are generally considered inefficient when it comes to proving algebraic expressions. On the other hand, Sigma protocols can be used to represent discrete logarithm information with a fixed number of exponents and can therefore be more efficient. Since there are discrete logarithm statements in the system, Σ-Protocols were used in the proofs because they are much more advantageous. 2.1.2 Proof of Encryption Equality-1 (Σ-EE1) Proof of Encryption Equality-1 (Σ-EE1) proves that the plaintexts of homomorphic ElGamal encryption encrypted with two different public keys pk1 and pk2 are equal to each other. φ1 = (φ1,L,φ1,R) represents the value encrypted with pk1, φ2 = (φ2,L,φ2,R) represents the value encrypted with pk2. In ElGamal encryption, Kurosawa demonstrated that employing identical random values for encrypting data across multiple ciphertexts is feasible [58]. This concept is integrated into our solution to optimize the efficiency of Σ-EE1. Therefore, φ1,L = φ2,L. The sender uses 2 different Σ-EE1 for three different ciphertexts when preparing the transaction. It shows that the plaintexts of the encrypted ciphertexts with the public keys of the receiver, sender 21 Prover Verifier u ∈R Zn a1←− gu a2←− (pk1/pk2) u a1, a2−−−−−−−−−−→ c ∈R Zq c←−−−−−−−−−− z←−n u+ c.r z−−−−−−−−−−→ gz ? = a1.φ c 1,L (pk1/pk2) z ? = a2.(φ1,R/φ2,R) c Figure 2.2 : Proof of Encryption Equality-1 (Σ-EE1). and regulatory agencies are equal to each other. In this way, the same amount that is deducted from the sender’s balance increases in the receiver’s balance, and regulatory agencies are provided with access to the transaction content in case of doubt. The protocol depicted in Figure 2.2 is a Σ-Protocol designed for the relation: {(g, pk1, pk2, φ1,L, φ1,R, φ2,R; v, r) : φ1,L = gr ∧ φ1,R = gv · pkr 1 ∧ φ2,R = gv · pkr 2} Proof. Completeness evidently holds, as gz = gu+c.r = gu.gc.r = gu.(gr)c = a1.φ c 1,L (2.1) and (pk1/pk2) z = (pk1/pk2) u+c.r = (pk1/pk2) u.((pk1/pk2) r)c = a2.(φ1,R/φ2,R) c (2.2) For special soundness, we assume that there are two accepting conversations (a1, a2, c, z) and (a1, a2, c′, z′) with c ̸= c′. Then we have: gz = a1.φ c 1,L, gz′ = a1.φ c′ 1,L ⇒ gz−z′ = φ c−c′ 1,L ⇔ φ1,L = g z−z′ c−c′ Therefore, the witness r holding φ1,L = gr is obtained as r =(z−z′)/(c−c′) . Similarly, 22 Prover Verifier u ∈R Zn a1←− gu a2←− pku a1, a2−−−−−−−−−−→ c ∈R Zq c←−−−−−−−−−− z←−n u+ c.r z−−−−−−−−−−→ gz ? = a1.φ c L pkz ? = a2.φ c R Figure 2.3 : Proof of 0 Encryption (Σ-E0). (pk1/pk2) z = a2.(φ1,R/φ2,R) c, (pk1/pk2) z′ = a2.(φ1,R/φ2,R) c′ ⇒ (pk1/pk2) z−z′ = (φ1,R/φ2,R) c−c′ ⇔ (φ1,R/φ2,R) = (pk1/pk2) z−z′ c−c′ Lastly, in order to demonstrate the property of special honest-verifier zero-knowledgeness, it is essential to compare the distributions of conversations with an honest verifier (following the protocol and utilizing the witness x as input) with the simulated conversations that deviate from the protocol, using only the common inputs. {(a; c; z) : u ∈R Zn; a1← gu; a2←− (pk1/pk2) u; z←n u+ cr} ,{ (a; c; z) : z ∈R Zn; a1← gz.φ−c 1,L; a2← (pk1/pk2) z.(φ1,R/φ2,R) −c } , with given challenge c. The distributions are the same, and each conversation occurs with a probability of precisely 1/n2. Since the protocol is special honest-verifier zero-knowledgeness, it is also honest-verifier zero-knowledgeness. 2.1.3 Proof of 0 Encryption (Σ-E0) Proof of 0 Encryption (Σ-E0) proves that the plaintext corresponding to the ciphertext is equal to 0. This is used by user’s commercial bank to create the person’s address in the ledger after the KYC step completed. 23 The protocol depicted in Figure 2.3 is a Σ-Protocol designed for the relation: {(g, pk, φL, φR; r) : φL = gr∧φR = g0 · pkr} Proof. Completeness evidently holds, as gz = gu+c.r = gu.gc.r = gu.(gr)c = a1.φ c L (2.3) and pkz = pku+c.r = pku.pkc.r = pku.(pkr)c = a2.φ c R (2.4) For special soundness, we assume that there are two accepting conversations (a1, a2, c, z) and (a1, a2, c′, z′) with c ̸= c′. Then we have: gz = a1.φ c L, gz′ = a1.φ c′ L ⇒ gz−z′ = φ c−c′ L ⇔ φL = g z−z′ c−c′ Therefore, the witness r holding φL = gr is obtained as r = (z−z′)/(c−c′) . Similarly, pkz = a2.φ c R, pkz′ = a2.φ c′ R ⇒ pkz−z′ = φ c−c′ R ⇔ φR = pk z−z′ c−c′ Lastly, in order to demonstrate the property of special honest-verifier zero-knowledgeness, it is essential to compare the distributions of conversations with an honest verifier (following the protocol and utilizing the witness x as input) with the simulated conversations that deviate from the protocol, using only the common inputs. {(a; c; z) : u ∈R Zn; a1← gu; a2←− pku; z←n u+ cr} ,{ (a; c; z) : z ∈R Zn; a1← gz.φ−c L ; a2← pkz.φ−c R } , with given challenge c. The distributions are the same, and each conversation occurs with a probability of precisely 1/n2. 2.1.4 Proof of Encryption-2 (Σ-EE2) 24 Prover Verifier u ∈R Zn a1←− gu a2←− (φL/φ ′L) u a1, a2−−−−−−−−−−→ c ∈R Zq c←−−−−−−−−−− z←−n u+ c.x z−−−−−−−−−−→ gz ? = a1.pkc (φL/φL′) z ? = a2.(φR/φ ′R) c Figure 2.4 : Proof of Encryption-2 (Σ-EE2). When the sender wants to create a transaction, the sender must have the random value r of the ciphertext in the ledger. But unfortunately this is not possible as other transactions occur that change the user’s state. For this reason, before sending a transaction, the user must retrieve the ciphertext from the ledger and create a new ciphertext by updating the random value. While doing this, it must show that it encrypts the same plaintext. For this reason, the system requires Σ-EE2. φ = (φL, φR) represents new ciphertext, φ ′ = (φ ′L, φ ′R) represents old ciphertext. The protocol depicted in Figure 2.4 is a Σ-Protocol designed for the relation: {(g, pk, φ , φ ′; r, v, x) : φR = gv · pkr∧φ ′ R = gv · pkr′} Proof. Completeness evidently holds, as gz = gu+c.x = gu.gc.x = gu.(gx)c = a1.pkc (2.5) and (φL/φ ′ L) z = g(r−r′).z = g(r−r′).u.g(r−r′).c.x = a2.pk(r−r′)c = a2.(φR/φ ′ R) (2.6) For special soundness, we assume that there are two accepting conversations (a1, a2, c, z) and (a1, a2, c′, z′) with c ̸= c′. Then we have: gz = a1.pkc, gz′ = a1.pkc′ ⇒ gz−z′ = pkc−c′ ⇔ pk = g z−z′ c−c′ 25 Therefore, the witness x holding pk = gx is obtained as x = (z−z′)/(c−c′) . Similarly, (φL/φL′) z ? = a2.(φR/φ ′ R) c, (φL/φL′) z′ ? = a2.(φR/φ ′ R) c′ ⇒ (φL/φL′) z−z′ = (φR/φ ′ R) c−c′ ⇔ φR/φ ′ R = (φL/φL′) z−z′ c−c′ Lastly, in order to demonstrate the property of special honest-verifier zero-knowledgeness, it is essential to compare the distributions of conversations with an honest verifier (following the protocol and utilizing the witness x as input) with the simulated conversations that deviate from the protocol, using only the common inputs.{ (a; c; z) : u ∈R Zn; a1← gu; a2←− (φL/φ ′ L) u; z←n u+ cx } ,{ (a; c; z) : z ∈R Zn; a1← gz.pk−c; a2← (φL/φL′) z.(φR/φ ′ R) −c} , with given challenge c. The distributions are the same, and each conversation occurs with a probability of precisely 1/n2. 2.2 Bulletproof In cases where transaction privacy is required, users must prove that the amount of money entering the transaction is greater than the amount leaving. In simpler terms, the sender must prove that the balance he has is more than the amount he wants to send. In a classic payment system, this can be achieved with a simple condition check. However, range proofs are needed in a payment system where transaction amounts and balances are wanted to be kept confidential. For instance, in Monero [59], ring signatures like Borromean Ring Signatures [60] were initially employed to prove that the processed value is positive and within a certain range. Although these methods provided the desired level of privacy, the drawback was the large size of the associated proofs. The most significant advancement in this regard is the Bulletproof protocol designed by Bünz et al. [61], which introduces a much more efficient approach in terms of proof size and verification time. Bulletproofs are non-interactive and composable inner-product range proof protocols that enable provers to demonstrate that multiple 26 processed values are within a given range with a succinct combined proof. Essentially, Bulletproofs build upon the inner-product arguments (IPA) introduced by Bootle et al. [62]. Bünz et al. [61] improved this design by halving the size of the underlying vector needed for commitment through a log2 n recursive transformation from an n-dimensional vector to a 1-dimensional vector. This significantly reduced the complexity of the original IPA. Additionally, in the Bulletproof protocol, the absence of a need to establish a trusted system at the outset distinguishes it from zero-knowledge proof methods like zk-SNARK [63], emphasizing its importance in terms of decentralization. The Bulletproof protocol, initially adopted in Monero, has recently been succeeded by the Bulletproof+ [64] protocol following a network update. Bulletproof+ employs a zero-knowledge weighted inner-product argument (zk-WIP) instead of IPA to generate range proofs in a shorter size compared to the short proof sizes achieved by the Bulletproof protocol. When comparing the time taken for the generation and verification of ZKPs in Bulletproof+ to those in the Bulletproof protocol, similar results are obtained. Similarly, the Bulletproof+ protocol allows for the proof of multiple values being within the specified range with a succinct combined proof. In the system proposed in the thesis, Bulletproof is used in two different ways in a transaction. Its primary purpose is to show that the user has sufficient funds for the transaction. The other one shows that the encrypted value is between 0 and 232−1. Formally, consider v∈Zp. Additionally, let V be an element in a group G, representing a Pedersen commitment to the value v using the randomness parameter γ . The objective of the proof system is to convince the verifier that v lies within the range of integers from 0 to 2n− 1. In simpler terms, the proof system aims to establish the following relation: { (g, h ∈G, V, n; v, γ ∈ Zp) : V = hγgv∧ v ∈ [0,2n−1] } (2.7) Bulletproof are drawn in Figure 2.5, 2.6 and 2.7 . Giving the notation here would be good for the traceability of the protocol. Bold fonts represent a vector. Let ⟨a,b⟩ = ∑ n i=1 ai · bi denotes the inner product. For a vector g = (g1, . . . ,gn) ∈ Gn and a ∈ Zn p, C = ga = ∏ n i=1 gai i ∈G. 27 Prover Verifier aL ∈ {0,1}n s.t. ⟨aL,2n⟩= v aR←− aL−1n ∈ Zn p α ∈R Zp A←− hαgaLhaR ∈G sL,sR ∈R Zn p ρ ∈R Zp S←− hρgsLhsR ∈G A, S−−−−−−−−−→ y,z ∈R Z∗p y, z←−−−−−−−−− Figure 2.5 : Bulletproof Part1. After completing the steps in Figure 2.5, with this setup Prover creates two vector polynomials l(X),r(X) in Zn p[X ] and quadratic polynomial t(X) ∈ Zp[X ]. l(X) = (aL− z ·1n)+ sL ·X ∈ Zn p[X ] r(X) = yn ◦ (aR + z ·1n + sR ·X)+ z2 ·2n ∈ Zn p[X ] t(X) = ⟨l(X),r(X)⟩= t0 + t1 ·X + t2 ·X2 ∈ Zp[X ] Prover Verifier τ1,τ2 ∈R Zp Ti←− gtihτi ∈G, i = {1,2} T1, T2−−−−−−−−−−→ x ∈R Z∗p x←−−−−−−−−−− l←− aL− z ·1n + sl · x ∈ Zn p r←− yn ◦ (aR + z ·1n + sR · x)+ z2 ·2n ∈ Zn p t̂←− ⟨l,r⟩ ∈ Zp τx←− τ2 · x2 + τ1 · x+ z2 · γ ∈ Zp µ ←− α +ρ · x ∈ Zp τx, µ, t̂, l, r−−−−−−−−−−−−→ Figure 2.6 : Bulletproof Part2. 28 Prover Verifier h′i←− h( y−i+1) i ∈G, ∀i ∈ [1,n] gt̂hτx ? =V z2 ·gδ (y,z) ·T x 1 ·T x2 2 P←− A ·Sx ·g−z · (h′)z·yn+z2·2n ∈G P ? = hµ ·gl · (h′)r t̂ ? = ⟨l,r⟩ ∈ Zp result←−−−−−−−− Figure 2.7 : Bulletproof Part3. The range proof depicted in Figure 2.5, 2.6 and 2.7 has perfect completeness, perfect honest verifier zero-knowledge and computational witness extended emulation. Proof. It is shown in Appendix C of [61]. 2.3 Fiat-Shamir Technique Fiat-Shamir is a technique used to make an interac- tive protocol non-interactive [65] This technique uses an algorithm that generates a result using a hash function instead of a traditional protocol where two parties (prover and verifier) share information and interact with each other. The Fiat-Shamir technique eliminates interactivity in the proofs described in this section. How to use the Fiat- Shamir Technique in proofs is not shown for simplicity. 2.4 Distributed Key Generation Threshold cryptography involves the implementation of techniques to distribute fundamental cryptographic schemes among multiple parties [66]. In this approach, the ownership or control of cryptographic keys is shared among a specified threshold of participants. Instead of relying on a single entity for key management, threshold cryptography enhances security by requiring collaboration and consensus among a designated subset of parties to perform cryptographic operations or access sensitive information. This distribution of cryptographic functions reduces the risk associated with a single point of failure, offering a more robust and resilient security framework. 29 In various scenarios, relying on a single entity for access to valuable assets is often deemed undesirable. For instance, accessing a personal safe within a bank may necessitate the use of two keys: one retained by the safe’s owner and another held by a bank employee. Similarly, in numerous cryptographic systems, restricting the possession of a secret key to a single entity is considered undesirable. Instead, the ownership or knowledge of a secret key should be distributed among multiple parties. This approach enhances security and mitigates risks associated with sole ownership, reflecting a principle of shared responsibility in safeguarding sensitive information. In the proposed system to ensure compliance, a group of authorized institutions, named “regulatory agencies”, are responsible for conducting audit procedures and other related tasks. They are able to access user data only by joint decision, through the use of threshold encryption. During the setup phase, regulatory agencies come together to create a private key for ElGamal Encryption. Before giving the definition of Pedersen Distributed Key Generation used [67], the definition of secret sharing are given [68]. Secret sharing schemes serve as the foundation for threshold cryptography. The concept involves dividing a secret into multiple shares in a way that allows the reconstruction of the original secret only when a predetermined number of shares are combined. If an inadequate number of shares is available, it becomes computationally infeasible to reconstruct the secret or any meaningful portion of it. This approach ensures that the security of the secret relies on a collaborative effort, with no single party possessing enough information to compromise the confidentiality of the original secret. The strength of the security lies in the threshold requirement for share reconstruction, providing a robust defense against unauthorized access. A secret sharing scheme involving a dealer D and participants (P1, ...,Pn) typically encompasses two essential protocols. • Distribution: The dealer D divides a secret s, ensuring that every participant Pi receives a share si, 1≤ i≤ n. • Reconstruction: s is recovered by combining shares sii , i ∈Q, of any qualified set Q⊆ P1, ...,Pn. 30 Secret sharing involves a dealer distributing a secret among participants, requiring collaboration for reconstruction, while distributed key generation (DKG) enables participants to jointly generate a cryptographic key without the need for a trusted party or dealer. The same distributed key generation used in FROST [69]. is used in the system. The steps of DKG are as follows. 1. Every participant Pi (regulatory agencies in our cases) chooses t random value and uses them as coefficients of polynomial fi(x) = ∑ t−1 j=0 ai jx j. 2. Each Pi calculates a proof of knowledge for the constant term in the polynomial. 3. Each Pi computes a commitment C⃗i = 〈 αi0, . . . ,αi(t−1) 〉 , where αi j = gai j and broadcasts C⃗i and the proof. 4. Each Pi, after receiving C⃗ℓ and the proof, verifies the proof. 5. Each Pi securely sends to other participants a secret (ℓ, fi(ℓ)). 6. Each Pi verifies their shares by calculating: g fℓ(i) ? = ∏ t−1 k=0 α ik ℓk mod q, after that calculates private sharing key by computing ski = ∑ n ℓ=1 fℓ(i) 7. The group public key is computed pk = ∏α j0 2.5 Homomorphic Threshold ElGamal Encryption Threshold encryption is a type of encryption scheme that typically allows a group of users to collaboratively decrypt a message. In this system, a shared private key is often divided, and the pieces of this key can come together to decrypt the message when a specific threshold is reached. Threshold encryption is useful for enhancing security and ensuring reliability. For instance, in situations requiring the participation of a group of individuals for a critical operation or data access, the shared private key pieces held by these individuals may need to come together. However, if a single individual cannot reach the threshold, they alone will be insufficient to decrypt the message. A variant of Elgamal Encryption 31 [70], Homomorphic Threshold ElGamal Encryption, is used in the proposed system. During the setup phase, regulatory agencies create the public key with distributed key generation and share it in the system. Then the sender encrypts the value he wants to send with this public key. If a suspicious transaction is detected, regulatory agencies can decrypt by consensus and see the value. A (t,n)−threshold encryption is a scheme involving participants (P1, ...,Pn) encompasses three essential protocols. • Distributed Key Generation: A protocol involving participants (P1, ...,Pn) to create a public key pk. In this process, each party Pi receives a private share xi (related to the private key x corresponding to pk) and a public verification key hi. The protocol’s execution depends on parameter t. • Encryption: A protocol that, given a plaintext message m and a public key pk, produces a ciphertext C for m under the public key pk. • Threshold Decryption: A protocol involving a group of t +1 parties (P1, ...,Pt+1) which, given a ciphertext C and individual inputs of private shares (x1, ...,xt+1), along with public keys (pk1, ..., pkt+1), jointly produces the plaintext message m. Homomorphic encryption is a cryptographic technique that enables certain compu- tations to be performed on encrypted data, producing an encrypted result. Upon decryption, the outcome matches the result obtained from performing the same operations on the original, unencrypted data. This can be shown in a more abstract way as follows: (E(x) and E(y) represent encryption of x and y respectively.) E(x+ y) = E(x)E(y) (2.8) The difficulty of solving the discrete logarithm problem is ensuring the security of the Homomorphic Elgamal Encryption scheme. The encryption includes the following three algorithms: 1. KeyGen. Private key x is randomly selected x $←− Z∗p and public key pk = gx is calculated. (In the system, the KeyGen phase has been replaced with Distributed Key Generation.) 32 2. Encryption. To encrypt the v value, a random r is selected r $←− Z∗p and c is calculated. (φL, φR) = (gr, gv · pkr) (2.9) 3. Decryption. To decrypt the ciphertext, φR/φ sk L is calculated. gv = φR/φ sk L (2.10) Then, the value v is found with brute force. Here, a smarter solution can be used with the Baby-step giant-step algorithm [71]. In the system, balances are kept encrypted in the ledger. When any transaction is sent, this balance is reduced before the plaintext is revealed. On the reciver’s side, the receiver’s balance increases homomorphically. Let’s say the sender’s balance is b. This balance is φ = (gr, gb · pkr) in the ledger. When it wants to send the value v to another user, it prepares the ciphertext φ ′ = (gr′, gv · pkr′). Assuming the transaction is verified, the new ciphertext is as follows: φ ′′ = (gr−r′, gb−v · pkr−r′) (2.11) 2.5.1 Threshold Decryption The following steps are followed to decrypt a text encrypted with a public key created with DKG. ∏ j ̸=i −x j xi−x j is the Lagrange coefficient. We represent it with λi. Suppose the ElGamal private key sk is distributed to n parties. That is, sk = ∑skiλi (2.12) To decrypt a ciphertext, i-party publishes φ ski L , and the proof is generated in order to demonstrate the honest contribution of the party. gv is calculated after summing the values from the parties. gb = φR/∏φ skiλi L (2.13) b is found by applying brute force to gb. 33 34 3. CONSTRUCTION In this section, the requirements of the system and existing entities are specified. Finally, the protocols used in the system are introduced and the performance analysis of the crypto algorithms used in the system is given. 3.1 Security and Privacy Requirements In this section, we define the privacy and security requirements that should be in the system. Transaction Integrity. It should not be possible for any person to transact on behalf of someone else and change their balance. Following a successful transaction between two users, it is imperative to update the accounts of both parties accurately, taking into account all relevant parameters. The transaction must occur even if the receiving party is offline. The balance increases and decreases on the sender, and receiver sides must be the same. Regulatory Mechanism. Regulation mechanisms such as KYC, AML, and CFT should be included in the system. Regulatory agencies should be able to see the details of the process and review them retrospectively when needed. In order for these mechanisms to be quickly processed, the sender should not be stored encrypted in the ledger. Bank and Financial Institutions Tasks. The duties of these institutions in traditional systems should also be provided in the solution. The user should be able to share the details of the past transaction with the institution without deceiving the institution. However, the institution cannot monitor past transactions without user permission. Non-repudiation. Once a sender has made a payment, he should not be able to deny it later. 35 Transaction Privacy. When a transaction is given, the transaction value should not be detected in cases other than auditing. In addition, the user balance should be kept encrypted in the ledger, and the balance should not be detected. Unlinkability. Given a transaction, the ownership of the assets used by the current transaction should not be linked to past transactions. It should not be possible to connect the receiver to another payment in the same system where the sender or receiver is located. 3.2 Stakeholders & Roles In this section, we describe the entities involved and their respective roles. The system consists of commercial banks (or any financial institutions) responsible for user registration and traditional bank tasks, the central bank responsible for currency issues and monetary policy, and regulatory agencies responsible for regulatory compliance. All entities are responsible for executing the validity of transactions and the blockchain network. Figure 3.1 shows the overview of the system. The direction of the arrows and the numbers in the figure do not indicate a specific order. The purpose of the arrows is to show the functions that take place between the entities. (1) represents User Registration, (2) represents Currency Issue, (3) represents Payment, (4) represents Abort Transaction Privacy, and (5) represents Abort Transaction Privacy for Bank. • Central Bank: The central bank issues the digital currency, which is accountable for the monetary policy and has the authority over the monetary supply at any point. However, the central bank has no control over the status of all users’ accounts and lacks trust in privacy because of the possibility of mass surveillance. This means it is unable to reveal the transferred values linked to a certain transaction. For the role of the central bank, we refer to [34]. • Users: As with any digital currency system, users of the system can take on the role of either the sender or the recipient when participating in a transaction involving digital currency. Users have no choice against regulatory agencies to protect the privacy of their past transactions. If the regulatory agencies decide that the user is 36 Figure 3.1 : The System. a potential criminal, they can abort the user’s privacy with the help of threshold cryptography. In addition, users have the ability to allow banks and financial institutions to review transactions. • Financial Institutions and Banks: Banks are responsible for making the user registration process. In the traditional banking system, banks also have various responsibilities, such as giving a credit score to the user and determining a credit card limit. In order to perform these functions, banks need to learn the balance and past transactions of the user. They can perform this operation cryptographically in line with the user’s consent. Likewise, financial institutions need to access the user’s transaction details to fulfill their duties in the traditional system. The user can share transaction details with financial institutions upon request. • Regulatory agencies: Our approach involves entrusting a group of authorized institutions, which we call regulatory agencies, with the task of conducting different audit procedures required for ensuring regulatory compliance. Regulatory agencies can access the data of the user’s transactions in case of doubt by joint decision. They can translate the encrypted transaction data into plaintext with the help of threshold cryptography and access the transaction details. 3.3 Balance Between Soft and Hard Privacy Auer et al. divided the privacy methods in CBDC systems into three [41]. These are hard privacy, soft privacy, and privacy with a balance between soft and hard. The 37 stakeholders in the system have been divided into shells according to the monitoring status of the transactions and the request to review the transactions. Hard privacy argues that all stakeholders in the system cannot see the transactions and that only the person with the private key can see the plaintext, that is, the user. Unfortunately, this will lead to the disappearance of regulatory mechanisms and is undesirable for CBDCs. On the other hand, soft privacy addresses the ability of payment information to move freely between different parties yet still protects it from external attacks through point-to-point encryption. While a system like this can be highly effective in terms of efficiency, its privacy features will not differ from those of current payment networks. As a result, it may not meet the privacy needs of users who are particularly concerned about protecting their information. We use hard privacy techniques between regulatory agencies and users in KAIME; we use a technique that converges to soft privacy, although we cannot say precisely soft privacy between the bank and the user. 3.4 Blockchain Selection Permissioned blockchains, unlike public blockchains, are private networks that have a limited group of participants and know the identities of the participants. These features make it advantageous for financial institutions and regulators. In CBDC applications, permissioned blockchains play an important role by increasing security and also meeting the regulatory requirement such as KYC. Smart contract support is critical in the system we offer. Smart contracts are programmable and automatable contracts. The blockchain needs to verify the accuracy of various zero-knowledge proofs. In addition, the blockchain to be chosen must contain simple primitive functions. Cosmos [72], Hyperledger Fabric [73], Avalanche [74], Polkadot [75] fit these criteria. Since the implementation of our proposed system is not within the scope of this thesis, we did not choose a specific blockchain. 38 3.5 Protocols In this section, the protocols used in the system are specified. The algorithms used in the protocols are described in Chapter 2. 3.5.1 System Initialization In this protocol, the public keys of the central bank and banks are recorded on the blockchain and the public key of the regulatory agencies is created. The public keys pkc, pkb of the central bank and banks are recorded on the blockchain. No specific algorithm for signing is specified in Chapter 2. For signature, a signature algorithm with elliptic curve-based EUF-CMA security (such as ECDSA, EdDSA) can be used. • Central Bank: The central bank runs KeyGen algorithm for signature and gets output as (pkc, skc) = (gskc , skc). (3.1) • Commercial Banks: A commercial bank runs KeyGen algorithm for signature and gets output as (pkb, skb) = (gskb, skb). (3.2) • Regulatory Agencies: Each regulatory agencies runs the distributed key generation algorithm with threshold parameters t for Homomorphic ElGamal Encryption and gets output as (pka, skai) = ( n ∏ i=1 gskai , skai) for 1≤ i≤ n. (3.3) 3.5.2 User Registration This protocol is required to create an account on the system for a user. A user needs to generate two key pairs. One is for signature; the other is to keep the balance in the ledger as encrypted and increase the received balances homomorphically encrypted balance. User runs KeyGen algorithm for signature and gets output as (pks,u, sks,u) = (gsks,u, sks,u). (3.4) 39 Then, the user runs KeyGen algorithm for Homomorphic ElGamal Encryption and gets output as (pke,u, ske,u) = (gske,u , ske,u). (3.5) By verifying the KYC step, the user is registered to the system through the bank. The Bank encrypts 0 using the user’s pke,u, runs Σ-E0 and signs this data and sends it to the blockchain. Bank runs encryption algorithm with pke,u gets output as φ = Enc(0, pke,u) = (gr, g0 · pkr e,u). (3.6) Then, the bank creates proof πE0 with running Σ-E0. πE0 = Σ-E0(φ , r, pke,u) (3.7) Lastly, signs datas and sends to blockchain. σ = Sign(onboarding, pke,u, pks,u, φ , πE0; skb) (3.8) Once the proof and signature are verified, the registration process is completed. 3.5.3 Currency Issue Only the central bank can issue currency. The central bank encrypts the value v, which it wants to issue, with the public key of the user and the public key of the regulatory agencies. φu = Enc(v, pku) = (gr, gv · pkr u) (3.9) φr = Enc(v, pka) = (gr, gv · pkr a) (3.10) Then, the central bank creates proof π-EE1 that the values in these two ciphertexts are the same. πEE1 = Σ-EE1(pke,u, pka, r) (3.11) Then, the central bank signs the datas. σ = Sign(issue, pke,u, φu, φr, πEE1; skc) (3.12) 40 Lastly, sends these to the ledger. The ledger is updated by checking the validity of the proofs and signature. The issued amount is added to the user’s encrypted balance. 3.5.4 Payment To start the payment process, the sender must first have the receiver’s public key and the public key between the receiver and the bank. Assume User1 is sender and User2 is receiver. (In this section, to avoid notation complexity, the ElGamal Encryption public key of the users is shown as pke,u = pku.) Then User1 accesses his old encrypted balance from the ledger and decrypts it. φo := (gro, gb · pkro 1 ) (3.13) b := Dec(φo, sk1) (3.14) User1 creates new ciphertext with same b to track the random value for creating range proof. φn := Enc(b, pk1) = (grn , gb · pkrn 1 ) (3.15) User1 encrypts the value v it wants to transfer with its own public key pk1, User2’s public key pk2 and the regulator agencies’ public key pka. φ1 := Enc(v, pk1) = (gr, gv · pkr 1) (3.16) φ2 := Enc(v, pk2) = (gr, gv · pkr 2) (3.17) φa := Enc(v, pka) = (gr, gv · pkr a) (3.18) User1 then runs two Σ-EE1. This proofs show that the plaintexts of 3 ciphertexts are equal to each other. π 1 EE1 = Σ-EE1(pk1, pk2, r) (3.19) π 2 EE1 = Σ-EE1(pk2, pka, r) (3.20) User1 also adds two range proofs to prevent the possibility of creating value out of thin air and to verify that there are sufficient funds in his account. π 1 bullet = Bulletproof(φ1, r) (3.21) 41 π 2 bullet = Bulletproof(φn−φ1,rn−r) (3.22) User1 runs Σ-EE2. πEE2 = Σ-EE2(φo, φn, sk1) (3.23) Finally, User1 signs the datas. σ = Sign(payment, pk1, pk2, φn, φ1, φ2, φa, π 1 EE1, π 2 EE1, π 1 bullet, π 2 bullet, πEE2; sks,1) (3.24) Lastly, sends these to the ledger. The ledger is updated by checking the validity of the proofs and signature. The amount is subtracted to the User1’s encrypted balance and the amount is added to the User2’s encrypted balance. 3.5.5 Abort Transaction Privacy Users use the public key of the regulators pka when performing the transfer protocol and the central bank currency issue protocol. Regulatory agencies apply the abort transaction protocol on the transaction or balance related to their shared ElGamal Encryption keys to see the content of transactions they consider suspicious. However, for this to happen, a sufficient number of regulatory agencies must reach a consensus. 3.5.6 Abort Transaction Privacy for Bank or Financial Institutions When the user wants to receive service from the bank or institution, the institution that will provide the service needs the details of the user’s past transactions. The user can give the encryption private key to the bank in order to present the contents of the encrypted transactions on the ledger to the bank, but in such a scenario, the bank will have the ability to see the future transactions of the user. Firstly, a bank or financial institution creates a one-time ElGamal Encryption publi