path: root/2021-offline/offline.tex

\documentclass{article}

\usepackage{url}
\usepackage{enumitem}

% The "Report on a Digital Euro" contains some discussion
% about offline payments in Section 5.1.7.
% We should make sure to reference/acknowledge this.
%
% Furthermore, the ECB seems to see the hardware requirements
% for a digital euro as a potential to "support the
% development of a common European end-user solution [...]
% thereby supporting the digitalisation of the European economy".
%
% Section 5.2 makes a rather bad mistake:  It first
% suggests that two types of digital euro can exist.
% One of them offline, one of them online.
% However, it then concludes that only the offline-euro
% should have anonymity: "However, this second type of digital euro would
% exclude the possibility of anonymity for users."


% We still need to mention the following issues:
%
% * Offline payments should be a fallback, not regular (migitate risks!)
% * Payments with anonymity should not be "second class" citizens

\title{Why a Digital Euro should be \\ Online-first and Bearer-based}
\author{Christian Grothoff \and Florian Dold}
\date{\today}
\begin{document}

\maketitle

The European Central Bank's ``Report on a Digital
Euro''~\cite{ecb2020digitaleuro} considers two distinct types of designs for a
digital euro. It argues that all functional requirements laid out in the report
can be fulfilled by operating the two systems in parallel:

\begin{enumerate}
  \item A bearer-based digital euro based on trusted hardware that can be used
    offline, anonymously, and without third-party intervention.
  \item An account-based digital euro that can be used online, is fully software-based
    and excludes the possibility of anonymity.
    % Actually, what's the difference to SEPA instant there?
\end{enumerate}

% why bad:
% * assumes that online systems can't be bearer based
% * assumes online systems can't be anonymous
% * now *three* systems need to be maintained (cash, online CBDC, offline) CBDC

The report does not discuss other choices of hybrid systems.  However, the
choice is more arbitrary than it might seem at first sight: bearer-based
systems are not necessarily offline payment systems, and online payment systems
do not need to exclude anonymity.

We argue that operating a bearer-based payment system to complement an
account-based CBDC in order to gain offline and privacy features is not a good
trade-off.  Adding permanent, regular offline capabilities via the bearer-based
payment instrument constantly exposes the CBDC to the severe issues inherent in
offline-capable payment systems.  Instead, the offline mode of operation should
be restricted to scenarios where it is actually required, which mitigates the
risks.

\section{Challenges of offline payments}

Payment processing involves a distributed, networked system.  Three properties
are desirable for distributed systems:
\begin{itemize}
\item Consistency: there is one coherent view of the state of
  the system and no contradictory believes held by different
  components.
\item Availability: the system is ``always'' able to provide
  its service, which implies making updates to the state to
  perform transactions for the system's users.
\item Partition tolerance: the system tolerates network or
  component failures which makes communication between
  parts of the distributed system temporarily impossible.
\end{itemize}

The well-known CAP theorem~\cite{cap} proves that it is impossible to design a
network protocol that simultaneously achieves all three properties.
For electronic payment systems, this means it is impossible to
simultaneously protect against double-spending (Consistency) while
operating (Available) offline (Partition-tolerance).  Thus, any
offline electronic payment system is left with one of the following
choices:

\begin{itemize}
\item Protect against double-spending by taking away
  control over computing from the user, typically using
  hardware security elements that prevent the user from
  accessing certain functions of the device.\footnote{
    A good example for such a design is~\cite{christodorescu2020twotier}.}
\item
  Retroactively identifying the user after network
  connectivity is restored, in privacy-preserving systems
  using conditional deanonymization, and attempting to recoup
  the losses from the double-spending party afterwards.\footnote{
    A classical example for such a design is~\cite{chaum1988offine}.}
\end{itemize}

There is no third choice. While there are minor variations how one
could implement these designs (like blaming the merchant and forcing
merchants to cover the double-spending cost), the list is basically
exhaustive.

\subsection{Hurting security}

If breaking the restrictive computing element's security properties
gives users the ability to access virtually unlimited funds, they
will.  Hardware protections typically fall against well-equipped
adversaries with plenty of time and expertise.\footnote{Examples of vulnerabilities in such
  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
an attack on ARMs TrustZone, a key observation of the report (that is not uncommon
for these types attacks) is:
\begin{quote}
  ``Unfortunately, the design issue outlined in this blog post is difficult to
  address, and at times cannot be fixed without introducing additional
  dedicated hardware or performing operations that risk rendering devices
  unusable.''
  -- \url{https://googleprojectzero.blogspot.com/2017/07/trust-issues-exploiting-trustzone-tees.html}
\end{quote}
So hardware security is hardly in a better shape than software security,
and issues can be significantly more expensive to fix.

Given a known vulnerability in an offline payment system, nation-state
attackers and organized crime may even find it advantageous to force
large-scale network outages to bring the payment system into a stage where
they can multi-spend.

Deanonymization is similarly problematic, as the identified individual
may actually be the victim of a computer crime. Furthermore, even if
the guilty party is identified, it is unclear that they would be able
to cover the costs of the multi-spend.  At scale, the resulting
potential attacks could endanger financial stability.


\subsection{Hurting informational self-determination}

Both of the above choices hurt the user's fundamental human right to
informational self-determination. Forcing users to use hardware that
they do not control is limiting their ability to control and customize
their digital lives.

Even in privacy-friendly systems (like those based on
Chaum~\cite{chaum1988untraceable}) where citizens can use digital cash to make
purchases anonymously, adding the ability to retroactively deanonymize
double-spending users implies that accidentally double-spending (say after
restoring from backup) voids the privacy assurances of the system.  This key
security property of the privacy-friendly systems would thus need to be
weakened and becomes brittle.

\subsection{Hurting availability}

A hardware-based solution not only limits availability to those users that can
afford the device, but also limits user's ability to make backups of their
digital cash. Thus, loosing the hardware will result in citizens loosing their
digital cash, something a software-based solution can avoid.  This drawback can
only be offset by revealing the user's identity to reveal a double spending
fraud without using trusted hardware, which means the solution would not offer
good privacy protections.

Similarly, in systems where double-spending is detected and later
penalized, the resulting financial risks will create pressures
to deny citizens with insufficient reputation or credit score

One argument for offline CBDC is the objective to improve availability
in situations where network access is unreliable. However, today
network availability is usually only problematic in areas where access
to electrical power is similarly limited. Thus, in these cases
preserving physical cash will help much more, while an offline CBDC is
unlikely to significantly improve availability.


\subsection{Hurting innovation}

In a world where everything is headed towards software solutions, a
mandatory hardware security solution for a CBDC is restrictive,
not just for customers but also for businesses who want to process
payments or offer services related to payments.  Furthermore, to
ensure the security of the solution, the production of approved
hardware devices would need to be strictly controlled, likely
reinforcing existing anti-competitive monopolies in the hardware
market.


\subsection{Hurting cash}

The ability to continue to use physical cash is priced by central
banks, citizens and experts in disaster management. In situations
with wide-spread and lasting power outages, digital systems fail,
and thus having cash as a fall-back is crucial. Children find it
easier to learn about money if it is physical and not obscured by
an electronic abstraction. Thus, availability and accessibility of
physical cash will always be unmatched by electronic solutions.
A CBDC that competes with cash by providing offline functionality
has a higher potential of harming the use of cash than a CBDC that
is online-only.


\section{Conclusion}

While in some situations, offline payments might be a desirable requirement,
adding offline payment systems have inherent and severe risks.
The exposure to these risks should be limited by only resorting to an offline
fallback mode of the payment system when actually required.

Discouraging the use of the offline fallback mode can be easily achieved by by
exposing the payee to counterparty risk.  In a system based on restricted
hardware elements, the payee would bear the risk in case of a compromised
hardware system.  In a system based on identifying offline double spenders /
cheaters, the payee would bear the risk in case the offline double spender /
cheater cannot be found and held accountable.

Preliminary results from a survey done by the ECB have shown that privacy is
regarded as one of the the most important feature by participants among
citizens and businesses.  Only providing privacy in the offline
payment instrument would make privacy a second class citizen, especially
as privacy is important in innovative online usages of a digital euro.

Thus, our improved suggestion for a secure, robust and privacy-friendly
digital euro would be the following hybrid:

\begin{enumerate}
  \item An online, bearer-based payment instrument with anonymity and income
    transparency features \cite{chaum1988untraceable,chaum2021issue}.
    Note that in this proposal, only one of the two parties (payer, payee)
    needs to have network connectivity.
  \item A limited and optional offline mode for the first payment system.
    The payee must decide whether to accept an offline payment,
    based on the counterparty risk.  The risk depends on the details
    of the offline payment implementation (hardware security vs. fraudulent party
    identification).
  \item Physical cash as a fallback for emergency situations where
    power outages or cyber attacks render a digital euro temporarily
    unusable.
\end{enumerate}

\section*{Acknowledgements}

We thank Thomas Moser for insightful comments on an earlier draft of this text.

\bibliographystyle{alpha}
\bibliography{literature}


\end{document}