offline.tex (11836B)
1 \documentclass{article} 2 3 \usepackage{url} 4 \usepackage{enumitem} 5 6 % The "Report on a Digital Euro" contains some discussion 7 % about offline payments in Section 5.1.7. 8 % We should make sure to reference/acknowledge this. 9 % 10 % Furthermore, the ECB seems to see the hardware requirements 11 % for a digital euro as a potential to "support the 12 % development of a common European end-user solution [...] 13 % thereby supporting the digitalisation of the European economy". 14 % 15 % Section 5.2 makes a rather bad mistake: It first 16 % suggests that two types of digital euro can exist. 17 % One of them offline, one of them online. 18 % However, it then concludes that only the offline-euro 19 % should have anonymity: "However, this second type of digital euro would 20 % exclude the possibility of anonymity for users." 21 22 23 % We still need to mention the following issues: 24 % 25 % * Offline payments should be a fallback, not regular (migitate risks!) 26 % * Payments with anonymity should not be "second class" citizens 27 28 \title{Why a Digital Euro should be \\ Online-first and Bearer-based} 29 \author{Christian Grothoff \and Florian Dold} 30 \date{\today} 31 \begin{document} 32 33 \maketitle 34 35 The European Central Bank's ``Report on a Digital 36 Euro''~\cite{ecb2020digitaleuro} considers two distinct types of designs for a 37 digital euro. It argues that all functional requirements laid out in the report 38 can be fulfilled by operating the two systems in parallel: 39 40 \begin{enumerate} 41 \item A bearer-based digital euro based on trusted hardware that can be used 42 offline, anonymously, and without third-party intervention. 43 \item An account-based digital euro that can be used online, is fully software-based 44 and excludes the possibility of anonymity. 45 % Actually, what's the difference to SEPA instant there? 46 \end{enumerate} 47 48 % why bad: 49 % * assumes that online systems can't be bearer based 50 % * assumes online systems can't be anonymous 51 % * now *three* systems need to be maintained (cash, online CBDC, offline) CBDC 52 53 The report does not discuss other choices of hybrid systems. However, the 54 choice is more arbitrary than it might seem at first sight: bearer-based 55 systems are not necessarily offline payment systems, and online payment systems 56 do not need to exclude anonymity. 57 58 We argue that operating a bearer-based payment system to complement an 59 account-based CBDC in order to gain offline and privacy features is not a good 60 trade-off. Adding permanent, regular offline capabilities via the bearer-based 61 payment instrument constantly exposes the CBDC to the severe issues inherent in 62 offline-capable payment systems. Instead, the offline mode of operation should 63 be restricted to scenarios where it is actually required, which mitigates the 64 risks. 65 66 \section{Challenges of offline payments} 67 68 Payment processing involves a distributed, networked system. Three properties 69 are desirable for distributed systems: 70 \begin{itemize} 71 \item Consistency: there is one coherent view of the state of 72 the system and no contradictory believes held by different 73 components. 74 \item Availability: the system is ``always'' able to provide 75 its service, which implies making updates to the state to 76 perform transactions for the system's users. 77 \item Partition tolerance: the system tolerates network or 78 component failures which makes communication between 79 parts of the distributed system temporarily impossible. 80 \end{itemize} 81 82 The well-known CAP theorem~\cite{cap} proves that it is impossible to design a 83 network protocol that simultaneously achieves all three properties. 84 For electronic payment systems, this means it is impossible to 85 simultaneously protect against double-spending (Consistency) while 86 operating (Available) offline (Partition-tolerance). Thus, any 87 offline electronic payment system is left with one of the following 88 choices: 89 90 \begin{itemize} 91 \item Protect against double-spending by taking away 92 control over computing from the user, typically using 93 hardware security elements that prevent the user from 94 accessing certain functions of the device.\footnote{ 95 A good example for such a design is~\cite{christodorescu2020twotier}.} 96 \item 97 Retroactively identifying the user after network 98 connectivity is restored, in privacy-preserving systems 99 using conditional deanonymization, and attempting to recoup 100 the losses from the double-spending party afterwards.\footnote{ 101 A classical example for such a design is~\cite{chaum1988offine}.} 102 \end{itemize} 103 104 There is no third choice. While there are minor variations how one 105 could implement these designs (like blaming the merchant and forcing 106 merchants to cover the double-spending cost), the list is basically 107 exhaustive. 108 109 \subsection{Hurting security} 110 111 If breaking the restrictive computing element's security properties 112 gives users the ability to access virtually unlimited funds, they 113 will. Hardware protections typically fall against well-equipped 114 adversaries with plenty of time and expertise.\footnote{Examples of vulnerabilities in such 115 hardware security systems include~\cite{samsung2017knox,arm2016alias,arm2016cache,arm2017boomerang,arm2017clkscrew,zhang2016truspy,intel2020sgx,intel2006survey,intel2020sgaxe,sim2019,sim2020,amd2019}, affecting all major hardware security architectures (Intel, Samsung, ARM, AMD, and SIM cards).} When Google published 116 an attack on ARMs TrustZone, a key observation of the report (that is not uncommon 117 for these types attacks) is: 118 \begin{quote} 119 ``Unfortunately, the design issue outlined in this blog post is difficult to 120 address, and at times cannot be fixed without introducing additional 121 dedicated hardware or performing operations that risk rendering devices 122 unusable.'' 123 -- \url{https://googleprojectzero.blogspot.com/2017/07/trust-issues-exploiting-trustzone-tees.html} 124 \end{quote} 125 So hardware security is hardly in a better shape than software security, 126 and issues can be significantly more expensive to fix. 127 128 Given a known vulnerability in an offline payment system, nation-state 129 attackers and organized crime may even find it advantageous to force 130 large-scale network outages to bring the payment system into a stage where 131 they can multi-spend. 132 133 Deanonymization is similarly problematic, as the identified individual 134 may actually be the victim of a computer crime. Furthermore, even if 135 the guilty party is identified, it is unclear that they would be able 136 to cover the costs of the multi-spend. At scale, the resulting 137 potential attacks could endanger financial stability. 138 139 140 \subsection{Hurting informational self-determination} 141 142 Both of the above choices hurt the user's fundamental human right to 143 informational self-determination. Forcing users to use hardware that 144 they do not control is limiting their ability to control and customize 145 their digital lives. 146 147 Even in privacy-friendly systems (like those based on 148 Chaum~\cite{chaum1988untraceable}) where citizens can use digital cash to make 149 purchases anonymously, adding the ability to retroactively deanonymize 150 double-spending users implies that accidentally double-spending (say after 151 restoring from backup) voids the privacy assurances of the system. This key 152 security property of the privacy-friendly systems would thus need to be 153 weakened and becomes brittle. 154 155 \subsection{Hurting availability} 156 157 A hardware-based solution not only limits availability to those users that can 158 afford the device, but also limits user's ability to make backups of their 159 digital cash. Thus, loosing the hardware will result in citizens loosing their 160 digital cash, something a software-based solution can avoid. 161 162 If a hardware-based solution were to enable users making arbitrary backups of 163 their digital cash, it would have to again include a mechanism to reveal the 164 user's identity if double spending is detected. In this case, the solution 165 would fail to offer good privacy protections. 166 167 Regardless of hardware or software solutions for offline payments, all such 168 systems where double-spending is detected and the double-spender is 169 retroactively identified and later penalized, the resulting financial risks 170 will create pressures to deny access to the payment system to citizens with 171 insufficient reputation or credit score. 172 173 One argument for offline CBDC is the objective to improve availability 174 in situations where network access is unreliable. However, today 175 network availability is usually only problematic in areas where access 176 to electrical power is similarly limited. Thus, in these cases 177 preserving physical cash will help much more, while an offline CBDC is 178 unlikely to significantly improve availability. 179 180 181 \subsection{Hurting innovation} 182 183 In a world where everything is headed towards software solutions, a 184 mandatory hardware security solution for a CBDC is restrictive, 185 not just for customers but also for businesses who want to process 186 payments or offer services related to payments. Furthermore, to 187 ensure the security of the solution, the production of approved 188 hardware devices would need to be strictly controlled, likely 189 reinforcing existing anti-competitive monopolies in the hardware 190 market. 191 192 193 \subsection{Hurting cash} 194 195 The ability to continue to use physical cash is prized by central 196 banks, citizens and experts in disaster management. In situations 197 with wide-spread and lasting power outages, digital systems fail, 198 and thus having cash as a fall-back is crucial. Children find it 199 easier to learn about money if it is physical and not obscured by 200 an electronic abstraction. Thus, availability and accessibility of 201 physical cash will always be unmatched by electronic solutions. 202 A CBDC that competes with cash by providing offline functionality 203 has a higher potential of harming the use of cash than a CBDC that 204 is online-only. 205 206 207 \section{Conclusion} 208 209 While in some situations, offline payments might be a desirable requirement, 210 adding offline payment systems have inherent and severe risks. 211 The exposure to these risks should be limited by only resorting to an offline 212 fallback mode of the payment system when actually required. 213 214 Discouraging the use of the offline fallback mode can be easily achieved by by 215 exposing the payee to counterparty risk. In a system based on restricted 216 hardware elements, the payee would bear the risk in case of a compromised 217 hardware system. In a system based on identifying offline double spenders / 218 cheaters, the payee would bear the risk in case the offline double spender / 219 cheater cannot be found and held accountable. 220 221 Preliminary results from a survey done by the ECB have shown that privacy is 222 regarded as one of the the most important feature by participants among 223 citizens and businesses. Only providing privacy in the offline 224 payment instrument would make privacy a second class citizen, especially 225 as privacy is important in innovative online usages of a digital euro. 226 227 Thus, our improved suggestion for a secure, robust and privacy-friendly 228 digital euro would be the following hybrid: 229 230 \begin{enumerate} 231 \item An online, bearer-based payment instrument with anonymity and income 232 transparency features \cite{chaum1988untraceable,chaum2021issue}. 233 Note that in this proposal, only one of the two parties (payer, payee) 234 needs to have network connectivity. 235 \item A limited and optional offline mode for the first payment system. 236 The payee must decide whether to accept an offline payment, 237 based on the counterparty risk. The risk depends on the details 238 of the offline payment implementation (hardware security vs. fraudulent party 239 identification). 240 \item Physical cash as a fallback for emergency situations where 241 power outages or cyber attacks render a digital euro temporarily 242 unusable. 243 \end{enumerate} 244 245 \section*{Acknowledgements} 246 247 We thank Thomas Moser for insightful comments on an earlier draft of this text. 248 249 \bibliographystyle{alpha} 250 \bibliography{literature} 251 252 253 \end{document}