-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy paththesis.tex
executable file
·3766 lines (3093 loc) · 237 KB
/
thesis.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
\documentclass[a4paper,12pt]{article} %Document class definition and text size settings
%
%Packages can be explored in more details: https://www.ctan.org/pkg/PACKAGE_NAME?lang=en
%
\usepackage{graphicx} %Allow using graphics in the text
\usepackage[top=2.5cm, bottom=2.5cm, left=3cm, right=3cm]{geometry} %Set the page margins
\usepackage{titlesec} %Package for title style
\usepackage[table]{xcolor} %make a colorful table
\usepackage{longtable} %Package so tables can be longer than one page
\usepackage{multirow} %Package so table cells can span multiple rows
% \usepackage[colorinlistoftodos]{todonotes} %Package so you can add nice TODO marks in your paper with \todo{TODO text...}
\usepackage[disable]{todonotes} %disables TODO notes
\usepackage{biblatex}
\addbibresource{thesis.bib}
%colors for risk categorization table
\definecolor{pool1}{HTML}{FF3333}
\definecolor{pool2}{HTML}{FF9933}
\definecolor{pool3}{HTML}{FFFF33}
\definecolor{pool4}{HTML}{99FF33}
\usepackage{hyperref}
% \usepackage{url} %Package in order to nicely use URLs
\usepackage{float} %Package to improves interface for defining floating objects like figures and tables
\usepackage[english, estonian]{babel} %Specifies possible languages of the document: English, Russian, and Estonian
\addto\captionsestonian{\def\refname{\centerline{References}}} %Changes references name and makes it center
\addto\captionsestonian{\def\listfigurename{\centerline{List of figures}}} %Changes drawing list name and makes it center
\addto\captionsestonian{\def\listtablename{\centerline{List of tables}}} %Changes table list name makes it center
\addto\captionsestonian{\def\contentsname{\centerline{Table of contents}}}
\usepackage[T2A,T1]{fontenc} %Font encodings for Russian and Estonian letters
\usepackage[utf8]{inputenc} %use UTF8 decodings
\usepackage{tocloft} %Control table of contents, tables, etc.
%\setlength\cftparskip{-2pt}
%\setlength\cftbeforechapskip{0pt}
\usepackage{amssymb} %For square itemized listss
\renewcommand{\labelitemi}{\tiny$\blacksquare$} %For square itemized lists
\usepackage{caption} %Needed to customise captions for tables and figures
\captionsetup{labelsep=period} %Set table and figure caption name to be separated with text with a period
\usepackage{verbatimbox} %To put program code in the center using Verbatim
\titlelabel{\thetitle.\quad} %Adds periods to the end of titles
\usepackage{times} %Sets font to Times New Roman
\usepackage{fancyhdr} %Allows more control of headers and footers
\setlength{\parindent}{0cm} %Set paragraph indentation to zero %consider removing this...
\usepackage{setspace} %Allows setting spacing between lines
% \onehalfspacing %Set spacing to 1.5x LaTeX
\linespread{1.25} %Set spacing to 1.5x like MS word
\usepackage{parskip}
%\setlength{\parskip}{1.5\baselineskip} % default for parskip
%\hangindent=0.7cm
\hyphenation{põhi-tekstis üliõpilas-kood lehe-küljed joonda-takse} %Correcting incorrect hyphenation (?)
\usepackage{eurosym}
\usepackage{quoting} %for quoting format
\quotingsetup{vskip=0pt} %for no vertical whitespace around quotings
% a bunch of stuff to make paragraph act as a subsubsubsection and numbered and formatted correctly
\usepackage{titlesec}
\setcounter{secnumdepth}{4}
\titleformat{\paragraph}
{\normalfont\normalsize\bfseries}{\theparagraph}{1em}{}
\titlespacing*{\paragraph}
{0pt}{3.25ex plus 1ex minus .2ex}{1.5ex plus .2ex}
\usepackage{enumerate} %for more control of ordered lists
\usepackage[none]{hyphenat} %kill hyphenation
\usepackage{ragged2e} % for nice justification in abstracts
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{listings}
\usepackage{graphicx}
\graphicspath{ {images/} }
% --- new commands ---
% creates hyperref using the name of a reference
\newcommand{\hypernameref}[1]{\hyperref[#1]{\nameref{#1}}}
% creates a hyperref in form "Table #" for a table
\newcommand{\hypertableref}[1]{\hyperref[#1]{Table \ref{#1}}}
% creates a hyperref in form "Figure #" for a figure
\newcommand{\hyperfigureref}[1]{\hyperref[#1]{Figure \ref{#1}}}
% creates a hyperref in form "Section #" for a section
\newcommand{\hypersectionref}[1]{\hyperref[#1]{Section \ref{#1}}}
% creates a hyperref in form "Section #" for a section
\newcommand{\hyperchapterref}[1]{\hyperref[#1]{Chapter \ref{#1} - \nameref{#1}}}
% make font look like code
\def\code#1{\texttt{#1}}
% ability to add line breaks in tables (by making a new table...)
% http://tex.stackexchange.com/questions/2441/how-to-add-a-forced-line-break-inside-a-table-cell
\newcommand{\specialcell}[2][c]{%
\begin{tabular}[#1]{@{}l@{}}#2\end{tabular}}
\begin{document}
\selectlanguage{english}
%------------------------------ENGLISH TITLE PAGE---------------------------------
\thispagestyle{fancy} %Page will include header and footer
\renewcommand{\headrulewidth}{0pt} %Remove header horizontal line
\renewcommand{\footrulewidth}{0pt} %Remove footer horizontal line
\headheight = 57pt %Set header heght (with regards to compiler suggestion)
\footskip = 11pt %Footer space
\headsep = 0pt %Decrease header and text line spacing distance to zero
\chead{ %Place the following text header to the center
\textsc{\begin{Large} %Make the following text have big letters
TALLINN UNIVERSITY OF TECHNOLOGY\\
\end{Large}}
Faculty of Information Technology\\
Department of Software Science
}
\vspace*{7 cm} %Make the page beginning and text line spacing correspond to the width
\begin{center} %Text centered
ITC70LT\\[0cm]
Christopher David Raastad\\
\begin{LARGE}
\textsc{Security Analysis of the Euro 2.0 Digital Currency Prototype\\}
\end{LARGE}
Master thesis\\[2cm]
\end{center}
\begin{flushright} %Align text to the right
Alexander Horst Norta\\[0cm]
PhD\\[0cm]
Associated Professor\\[0cm]
\end{flushright}
\cfoot{Tallinn \\ 2017} %Add location and year to the header
%\renewcommand{\headrulewidth}{0pt} %Remove the footer horizontal line
\pagebreak %End of page
%------------------------------TIITELLEHT EESTI KEELES---------------------------------
\selectlanguage{estonian}
\thispagestyle{fancy} %Leht sisaldab päist ja jalust
\renewcommand{\headrulewidth}{0pt} %Eemaldab päisest horisontaalse joone
\renewcommand{\footrulewidth}{0pt} %Eemaldab jalusest horisontaalse joone
\headheight = 57pt %Paneb paika päise laiuse (vastavalt kompilaatori soovitusele)
\footskip = 11pt %Jaluse ruum
\headsep = 0pt %Vähendab päise ja teksti vahelise kauguse nullini
\chead{ %Paigutab järgneva teksti päises keskele
\textsc{\begin{Large} %Tekst suurtähtedega ja suuremaks
tallinna tehnikaülikool\\
\end{Large}}
Infotehnoloogia teaduskond\\
Tarkvarateaduse instituut
}
\vspace*{7 cm} %Tekitab lehe alguse ja teksti vahele tühja ala vastava laiusega
\begin{center} %Tekst keskele
ITC70LT\\[0cm]
Christopher David Raastad\\
\begin{LARGE}
\textsc{Euro 2.0 Digitaalse Valuuta Prototüübi Turvalisusanalüüs\\}
\end{LARGE}
Magister\\[2cm]
\end{center}
\begin{flushright} %Joondab teksti paremale
Alexander Horst Norta\\[0cm]
PhD\\[0cm]
Dotsent\\[0cm]
\end{flushright}
\cfoot{Tallinn \\ 2017} %Lisab asukoha ja kuupäeva jalusesse
%\renewcommand{\headrulewidth}{0pt} %Eemaldab päisest horisontaalse joone
\pagebreak %Lehe lõpp
%----------------------------LIST OF TODOS----------------------------------
\listoftodos
\newpage
%---------------------------AUTHOR DECLARATION-------------------------
\selectlanguage{english}
\section*{\begin{center}
Author’s declaration of originality
\end{center}}
I hereby certify that I am the sole author of this thesis. All the used materials, references to the literature and the work of others have been referred to. This thesis has not been presented for examination anywhere else.
Author: Christopher David Raastad
May 18th 2017
\pagebreak
\section*{\begin{center}Abstract\end{center}}
Digital money in the form of cards, bank accounts, and online payments has been around for the last few decades. The cryptocurrency Bitcoin emerged as a completely new paradigm of storing and transferring value outside of the regulations and governments of the traditional financial system. The blockchain distributed ledger consensus technology powering Bitcoin inspired similar cryptocurrency clones, specialized use cases, and the creation of a general purpose distributed application computing platform Ethereum. Despite the innovations in value transfer, cryptocurrencies have a very niche use in daily transactions outside the circle of enthusiasts. The problem is the lack of incentive for users and merchants alike to hold all of their assets in a cryptocurrency. Significant cost and friction is associated with moving funds in and out of cryptocurrencies through exchanges and payment processors as well as the risk of wildly fluctuating exchange rates. The Euro 2.0 Foundation presents a fiat backed, fully regulated, government backed digital currency to alleviate these shortcomings. This thesis presents a security analysis of the proposed Euro 2.0 digital currency prototype. We present the features and architecture of the Euro 2.0 digital currency, a fusion of traditional client server components, Estonia ID card authentication, and Ethereum smart contract decentralized distributed computing platform. Then we present a change analysis of the impact of the Euro 2.0 digital on the stakeholders including users, merchants, banks, and government. Finally we present an information system security risk analysis based on the OCTAVE Allegro methodology of key information assets user money, Ethereum admin keys, and user identity. From the security analysis we present suggestions and mitigation strategies of the biggest risks of a hybrid centralized and decentralized Euro 2.0 digital currency system.
\todo[inline]{Fill in English abstract thesis details \ldots}
The thesis is in English and contains 112 pages of text, 6 chapters, 3 figures, 75 tables.
\pagebreak
\selectlanguage{estonian}
\section*{\begin{center}Annotatsioon\end{center}}
\sloppy Digitaalne raha on kaartide, pangakontode ja internetimaksete kujul olemas olnud juba aastakümneid. Krüptoraha Bitcoin kujundas täiesti uue paradigma väärtuste hoidmisele ja ülekannete tegemisele väljaspool traditsiooniliste finantssüsteemide regulatsioone ning valitsust. Plokiahela abil loodi ühtse tehnoloogiaga avalik raamatupidamisregister, olles inspireeritud sarnaste krüptorahade kloonidest, erilistest kasutamisjuhtudest ja üldotstarbelise rakenduste arvutamise platvormi Ethereum loomisest. Vaatamata väärtuste ülekannete protsesside innovatsioonile on krüptoraha väljaspool entusiastide ringe igapäevakasutuses siiski niši staatuses. Probleem tuleneb sellest, et kasutajatel ning kaupmeestel puuduvad stiimulid kõiki oma varasid krüptovaluutas hoida. Lisaks valuutakursside suurtele kõikumistele seostatakse krüptoraha märkimisväärseid kulusid ja huvide vastuolusid raha liigutamisega krüptovaluutasse ja tagasi valuutavahetuste ja maksete töötlemise protsesside käigus. Euro 2.0 Sihtasutus esitleb täielikult reguleeritud, ametlike volitustega ja valitsuse poolt toetatud digitaalvaluutat, millega soovitakse kõiki neid puudusi leevendada. Käesolev magistritöö esitab kavandatava Euro 2.0 digitaalvaluuta prototüübi turvalisusanalüüsi. Töös on välja toodud Euro 2.0 digitaalvaluuta omadused ja ülesehitus, traditsiooniliste kliendiserverite lülide, Eesti ID-kaardi autentimise ning Ethereum targa lepingu detsentraliseeritud hajusandmetöötluse platvormi integratsioon. Järgmisena on esitatud analüüs Euro 2.0 digitaalvaluuta mõjust huvigruppidele, hõlmates kasutajaid, kaupmehi, panku ja valitsust. Lõpetuseks tuuakse välja infosüsteemi turvariskid toetudes OCTAVE Allegro kasutajate varade olulise teabe metoodikale, Ethereumi haldajate võtmete ja kasutajate identideedi analüüsile. Turvalisusanalüüsi põhjal esitatakse soovitused ja leevendamise strateegiad hübriid-tsentraliseeritud ja detsentraliseeritud Euro 2.0 digitaalvaluutasüsteemi suurimatele riskidele.
\todo[inline]{Täitke eesti keele annotatsiooni lõputöö detailid \ldots}
Lõputöö on kirjutatud inglise keeles ning sisaldab teksti 112 leheküljel, 6 peatükki, 3 joonist, 75 tabelit.
\pagebreak
\selectlanguage{english}
\section*{\begin{center}Table of abbreviations and terms\end{center}}
\begin{tabular}{p{2cm} p{13cm}}
AML & \textit{Anti Money Laundering}, processes implemented by financial institutions to hinder money laundering activities and comply with regulations \\
API & \textit{Application Programming Interface}, instructions for programmatically communicating with servers \\
BTC & \textit{Bitcoin} cryptocurrency abbreviation \\
CMB & \textit{Citizenship and Migration Board} of Estonia \\
CTF & \textit{Counter Terrorist Financing}, processes implemented by financial institutions to hinder terrorist financing and comply with regulations\\
ETC & \textit{Ether}, Ethereum cryptocurrency abbreviation \\
ISSRM & \textit{Information Systems Security Risk Management} \\
JSON & \textit{JavaScript Object Notation}, a serialization format for REST API communication \\
KYC & \textit{Know Your Customer}, proccesses implemented by financial institution to identify and verify customer identities to aid in AML and CTF as well as comply with regulation\\
LDAP & \textit{Lightweight Directory Access Protocol}, particular that hosted by SK for Estonian PICs \\
PIC & \textit{Personal Identity Code}, issued by the Estonian CMB associated with an Estonian ID card\\
PKI & \textit{Public Key Infrastructure}, used in cryptocurrency cryptography\\
REST & \textit{REpresentational State Transfer}, a web server communication architecture \\
RPC & \textit{Remote Precedure Call}, external function call from application \\
RSA & widely used public-key crypto-system for secure data transmission \\
SK & \textit{Sertifitseerimiskeskus} (Certification Center), SK ID Solutions AS, the only Certificate Authority (CA) in Estonia for the Estonian ID card system \\
TLS & \textit{Transport Layer Security}, cryptographic protocol to provide secure communication over a computer network \\
UX & \textit{User Experience}
\end{tabular}
\pagebreak
\tableofcontents
\newpage
\listoffigures
\pagebreak
\listoftables
\pagebreak
\section{Introduction} \label{sec:1}
\subsection{The Road to Digital Currency} \label{ssec:1.1}
Payments today are the laggard of the information age. While emails can be sent instantly for free anywhere in the world, money is either slow and/or expensive to move digitally. Bank transfers can take days, only work during business hours, and have high fees across borders. Card payments are instant, but subject merchants to high fees and chargeback risks. Paypal brought convenient payments to the web, but at a high cost to accept payments and move funds internationally. Fintech companies like Venmo and Square can create the illusion of fast payments, but still take days to settle in the background with the potential chargeback risks. This cost comes from the highly regulated centralized financial payments systems with little economic incentive to reduce fees. A usable digital currency would greatly alleviate this friction in transferring value that theoretically costs the economy an estimated 1\% of GDP annually\cite{kaarmann2013cost}.
Bitcoin was the first successful implementation of a decentralized digital currency. Nakamoto's peer to peer digital cash system completely sidestepped the existing financial system\cite{nakamoto2008bitcoin}. Its clever proof of work consensus protocol, economic incentives for nodes to maintain the network, pseudo anonymity, and irreversible transactions implemented on the public ledger blockchain technology has been called ``the next technological revolution''\cite{BlockchainRevolution}. Hundreds of Altcoins followed Bitcoin's lead borrowing from the blockchain technology to implement other flavors of cryptocurrency and digital asset management\cite{coinMarketCap}. Despite the rapid growth of the cryptocurrency ecosystem, everyday payments are a niche use case for digital currencies, which are more commonly used for investment and financial speculation\cite{Khairuddin:2016:EMB:2851581.2892500}. Merchants accepting Bitcoin payments are in fact immediately converting funds to a fiat currency for a non negligible fee. Bitcoin exchanges are high cost gatekeepers between the cryptocurrency and financial systems.
What is missing today are incentives for parties on both sides of transactions to hold assets end to end in digital currency. The cost and friction of moving between two financial systems, crypto and fiat, eliminates the perceived benefits of cryptocurrencies. The Euro 2.0 project aims to implement fiat currency on digital currency technology in order to reduce payment friction by eliminating unnecessary financial intermediaries. The unanimous adoption of Estonian ID card in Estonia and the rise of the Ethereum distributed application platform make a usable digital currency prototype possibly.
Can a regulated, government backed, digital currency system be securely built? So far, no academic literature has explored the security of real money moving through cryptocurrency pipes. This thesis introduces the Euro 2.0 digital currency prototype, its impact on stakeholders in the finance, and assesses the security risks of the proposed implementation to determine whether this prototype can in fact reasonably support a national digital currency.
\subsection{Research Questions} \label{ssec:1.2}
This thesis analyzes the feasibility of the proposed Euro 2.0 digital currency by exploring the following research question:
\begin{quoting}
\textbf{RQ: }\textit{How do we assure that the proposed Euro 2.0 digital currency system does not have any major security flaws compromising its usefulness as a monetary system?}
\end{quoting}
In which we explore in sub research questions:
\begin{quoting}
\textbf{RQ1: }\textit{How do we describe the features and components of the Euro 2.0 digital currency system for a security analysis?}
\end{quoting}
\begin{quoting}
\textbf{RQ2: }\textit{How does adoption of Euro 2.0 digital currency impact the relationship with money for key stakeholders: users, merchants, banks, and governments?}
\end{quoting}
\begin{quoting}
\textbf{RQ3: }\textit{How do we assess the security risks of Euro 2.0 digital currency system and potential impact on stakeholders?}
\end{quoting}
The result of exploring \textbf{RQ} will result in one of the following outcomes:
\begin{itemize}
\item The Euro 2.0 system is free from significant risks in functioning as a digital monetary system.
\item The Euro 2.0 system has one or more serious risks that need to be addressed before significant adoption.
\end{itemize}
In order to do a risk analysis, the key features of the Euro 2.0 system need to be identified and implementation details described by answering \textbf{RQ1}. Following a clear description of the system, \textbf{RQ2} explores the current and future relationship with money of key stakeholders after adoption of Euro 2.0. This exploration of the stakeholders' relationship with money guides the security analysis to asses the impact of realized risks discovered in \textbf{RQ3}. The severity and likelihood of realized risks to the monetary system lead to an answer to the original research question \textbf{RQ}.
\subsection{Research Methods} \label{ssec:1.3}
The thesis utilizes methods from design science and Information Systems Security Risk Management (ISSRM) to approach the research questions. The main contributions are:
\begin{itemize}
\item Presentation of the features and components of the proposed Euro 2.0 digital currency prototype
\item Change analysis of stakeholders adopting the Euro 2.0 digital currency
\item Security Risk analysis of the Euro 2.0 prototype
\item Design recommendations for Euro 2.0
\end{itemize}
The features and components are presented by a comprehensive review of the Euro 2.0 codebase (\hyperref[ssec:a.1]{Appendix A.1}). The change analysis is based on an interpretation of the Change Formula\cite{changeFormula2014} described in \hypersectionref{ssec:4.2}. The security risk analysis employs the OCTAVE Allegro risk analysis framework presented in \hypersectionref{ssec:2:issrmFramework} in which design recommendations follow from the analysis.
\subsection{Structure of the Thesis} \label{ssec:1.4}
\hyperchapterref{sec:2} will give an overview of the existing body of knowledge needed to understand the remaining chapters including traditional finance, Bitcoin, Tether, Ethereum, Estonia ID card, and ISSRM frameworks. \hyperchapterref{sec:3} will describe the motivation, features, smart contracts, and implementation architecture of the Euro 2.0 digital currency prototype needed for a security analysis. \hyperchapterref{sec:4} will perform a change analysis to better understand the socio-technical impact of stakeholders adopting the Euro 2.0 digital currency. In \hyperchapterref{sec:5} we will perform a OCTAVE Allegro information security risk analysis of the Euro 2.0 system resulting in mitigations proposals and design recommendations. Finally \hyperchapterref{sec:6} will summarize the thesis, answer the research question, and suggest future avenues of research.
\pagebreak
\section{Bridge of Knowledge} \label{sec:2}
\subsection{Introduction} \label{ssec:2:introduction}
In this chapter we present background research needed to understand the rest of the thesis in Chapters \hyperref[sec:3]{3}, \hyperref[sec:4]{4}, and \hyperref[sec:5]{5}. \hypersectionref{ssec:2:finance} presents the costs associated with the currency and payments. \hypersectionref{ssec:2:cryptocurrencies} presents Bitcoin, Tether, and research analyzing trust in payments needed to understand the motivation behind Euro 2.0. \hypersectionref{ssec:2:ethereum} presents an overview of Ethereum including accounts, messages, execution model, and the high level programming language Solidity. \hypersectionref{ssec:2:estoniaIdCard} presents background on the Estonian ID card system. Then in \hypersectionref{ssec:2:issrmFramework} we present findings on ISSRM frameworks, security risk patterns of distributed systems, and our decision to choose OCTAVE Allegro as a risk analysis framework for this thesis.
\subsection{Currency and Payments} \label{ssec:2:finance}
Money and payments haven been part of human society since the dawn of civilization. Currency grew out of the need to transport value of goods without transferring the goods themselves. First came gold, silver, and other precious metals to trade in exchange for goods and services. Later in the 1600s, notes were issued by the Bank of England backed by silver and the practice spread to every country in the Western world. Banks became the de facto institutions to store and transfer value in government issued currencies. By the 1950s the USA was the first government to eliminate physical backing (silver) to create a fiat currency only backed by the trust of the US Government and Federal Reserve. Today there are no countries left physically backing government issued notes; money is entirely trust that society accepts the government backed notes for exchange of goods and service.
As early as the 1960s banks were some of the first adopters of information technology, using computers and databases to overhaul paper processes. The first electronic access of money was the Credit Card, its earliest usage was a credit exchange between private companies in the USA in the 1920s, Diners’ Club, Inc. for consumers in 1950, American Express Travel and Entertainment card in 1958, and finally the founding of VISA in 1976 to spread the concept globally\cite{britannica2016creditcard}. Debit cards directly debiting bank accounts hit market as early as 1966 in the USA, long before mass consumer adoption of technology, gaining popularity in the 80s and 90s with the rise of ATM network and merchant acceptance\cite{collins2011debitcard}. With all of these developments, the Financial institutions of banks and payment processors are the heart of system and source of high fees. Credit Cards cost merchants 1-3\% transaction fees and carry the risk of costly chargebacks at the benefit of consumer convenience. Debit cards are slightly better, charging about \euro0.45 per swipe \cite{kaarmann2014government}.
With consumer adoption of the internet came personal windows into our finances via online banking. Bank transfers can take days to settle and only work during working hours of weekdays. International bank transfers can take even longer and with a heavy 3-5\% fee. Many transactions in financial systems, such as stock trades, can happen ``instantly'' but in fact take days to settle on the backend due to legacy paper based processes. The financial industry and has only in this time created pretty facades to their inefficient processes. Paypal succeeding to bring payments to the internet, but is still atrociously expensive to send and receive card payments, charging 2.9\% + \$0.30 USD per transaction and adding a 2.5\% fee on top of a bank dictated currency conversion spread for international conversion of funds\cite{paypal2017fees}.
Why all the friction? In France, the economic cost of payments is an estimated at 1\% of GDP annually \cite{kaarmann2013cost}. Elsewhere an estimation was not found, but we can assume this tax on the economy is non-trivial since financial institutions designed themselves to profit from friction in payments. International money transfer moves between four or more levels of banks, each taking a small slice of the fee, until funds reach the destination bank. Consumer banking creates the illusion of free domestic transfers though subsidization, but makes the meat of their profit from transactions data to sell customers credit and loan. Institutional investment banks gamble with our money every day on Wall Street, when things get out of hand, we have the Financial meltdown of 2008. Even post financial crisis, too big to fail banks have barely changed there ways. With increased regulatory costs and greedy shareholders comes even less economical incentive to reduce the cost of payments.
\subsection{Cryptocurrencies and Trust} \label{ssec:2:cryptocurrencies}
\subsubsection{Bitcoin} \label{sssec:2:bitcoin}
Following the 2008 crisis, Satoshi Nakamoto quietly released \textit{Bitcoin: A Peer-to-Peer Electronic Cash System}\cite{nakamoto2008bitcoin} aiming to solve the business problem \textit{``How do I create a system where nobody can stop me spending my own money?''}\cite{brown2016introducing}. A decentralized system \textit{``based on cryptographic proof instead of trust''} allows parties to transact with each other directly without a trusted third party. Double spending is prevented by a \textit{``peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions"}\cite{nakamoto2008bitcoin}. This computational proof is distributed in the amongst participant nodes in the network in a voting scheme governed by a cryptographic puzzle known as \textit{proof-of-work}. Nodes compete to publish a block of transactions in the system for a reward of Bitcoins and transaction fees. The proof of work mechanism probabilistically limits the network to publish a new block of transactions approximately every ten minutes. Blocks reference previous blocks and once published are irrevocable unless another node were to rewrite history by solving the cryptographic puzzle multiple times in a short timespan, which is computationally infeasible. Hence transactions on the Bitcoin network are irreversible. This chain of blocks of transactions cryptographically tied in a historical record is the \textit{blockchain}. Nodes are incentivized to act in their best interest and maintain the network to claim their reward, currently worth 12.5 BTC per block and more than 21,000 USD at the time of this writing\cite{btcPrice}, a process commonly known as \textit{mining}. A published block has to be valid in history, i.e. no double spent bitcoins and a valid proof-of-work solution, to be accepted by the network. With this consensus mechanism, the Bitcoin peer-to-peer network maintains itself without a centralized entity\cite{nakamoto2008bitcoin}.
Users of the bitcoin network enjoy the possibility of pseudo-anonymity in using the system. Transactions are a chain of digital signatures. Public keys are the addresses which can be thought of accounts. Private keys are the proof of ownership of a public key which allow the right to claim ownership and spend all coins previously sent to that address. A user only requires a private and public key tied to some unspent tokens in order to use the system\cite{nakamoto2008bitcoin}. All transaction hashes and public keys addresses are published in blocks on the blockchain \textit{public ledger}. Anyone can view produced blocks and transactions by downloading a Bitcoin client or browsing an online tool like Blockchain Info\cite{blockchaininfo}. Pseudo-anonymity comes from the fact once the a Bitcoin address is linked to a real identity, all present, past, and future transactions are visible on the public ledger. Graph analysis of the the entire Bitcoin blockchain can reveal clues of transaction patterns, owners of addresses, and networks of miners\cite{Ron2013}.
Bitcoins counteracts inflation of traditional monetary systems with a limited supply, designed to emulate a growth curve similar to gold\todo{cite gold}. This supply is algorithmically limited to 21,000,000 BTC, which will be all mined into circulation around year 2140. In Theory, Bitcoin will become more and more valuable overtime because of its rarity\todo{Bitcoin supply vs inflation}, hence an attractive mechanism for long term savings.
Bitcoin transactions are geographically independent. Since the entire global network runs distributively on the internet and not controlled by a central party, transactions can happen anywhere a client has enough internet bandwidth to broadcast to the network. Theoretically \todo{find reference for bitcoin independent of geopolitical entities} Bitcoin is a completely governmental independent store and growth of value, but its price does fluctuate with geopolitical events in China, USA, and UK (Brexit)\todo{find reference relating Bitcoin price and geopolitical events}.
Currently Bitcoin has a major benefit low cost transactions, since miners are incentivized enough by Bitcoin rewards mining new blocks of transactions. When Bitcoin supply approaches its upper bound, already 99\% of Bitcoins will be mined by 2036, then transaction fees must take over as incentive for miners to maintain the network\todo{find reference for network transaction fees}.
\subsubsection{Tether} \label{sssec:2:tether}
Tether is the project most resembling the Euro 2.0 digital currency system by supporting \textit{``fiat currencies on the Bitcoin blockchain.''}\cite{tether}. The Tether coin is built on top of the Omni Protocol, which coins to be created by embedding data in Bitcoin transactions\cite{omniProtocolSpec}. The Hong Kong based company Tether Limited holds a reserve of Fiat currency, currently USD and EUR, that can be converted to and from Tethered TUSD and TEUR on Bitcoin blockchain. TUSD and TEUR can be transferred, stored, and spent like Bitcoin. Tether Limited maintains a proof of reserve that at any given time the balance of fiat currency held in the reserves will be equal to (or greater than) the number of tethers in circulation. Tethers in circulation exist as a decentralized digital currency but reserve assets must be administered by centralized Tether Limited. Tether transacts just like Bitcoin, hence, is subject to the same trust and regulatory issues outlined in the next section.
\subsubsection{Anonymity, Regulation, and Trust} \label{sssec:2:anonymityRegulationTrust}
Bitcoin gained early attention for the infamous Silk Road, the ``Ebay for Drugs''\cite{EbayForDrugs}. The website amassed over 1000 vendors, tens of millions of dollars of revenue, and triple digit yearly growth until it was shutdown by the FBI in 2013 after two and a half years operation\cite{NotAnEbayForDrugs}. The buyers were protected in escrow Bitcoin transaction, only releasing payment to the seller if the buyer was completely satisfied. Bitcoin allowed payments amongst parties that can never trust each other in real life. \textit{``Anonymity and lack of regulation which is meant to free users from central authorities also empowers drug dealers and money launderers''}\cite{Ali:2015:BPU:2990603.2990632}.
Sas and Khairuddin interviewed 20 Bitcoin users to explore the challenges and opportunities of Bitcoin users with respect to technological, social, and institutional trust\cite{sas2016design}. The economic rationale of users holding Bitcoin came from distrust in governments and banks directly having access to bank account funds, fear of unfavorable fiat currency exchange rates due to inflation, economic downturn, or political events, and speculation that Bitcoin will become more and more valuable over time. Bitcoin users are not discouraged by the early reputation of the currency for drugs and money laundering. Ironically, they found \textit{``spending bitcoins as a currency appears as an exception rather than a norm''}. Bitcoin behaves more like a commodity than a currency\todo{cite why Bitcoin is more like a commodity}. Websites and stores accepting Bitcoin do so more for marketing then actual value of the currency\todo{cite why stores and merchants accept bitcoin}. Merchants pay a 1\% transaction fee to accept Bitcoin payment for fiat currency priced goods with payment provider to directly convert the Bitcoin to a fiat currency bank account, showing little incentive to hold their Bitcoin\todo{cite cost to accept Bitcoin}. The short term fluctuations of value and difficult to grasp price with regards fiat currency makes it unattractive for end to end commerce in Bitcoin\todo{cite short term fluctuations and pricing}.
From the findings of Ali, Clarke, and McCorry \textit{``Bitcoin’s strengths and weaknesses both derive from the same essential ideological and architectural design choices''}\cite{Ali:2015:BPU:2990603.2990632}. Sas and Khairuddin support this statement with their findings of Bitcoin user experiences with regards to the blockchain's characteristics and their impact on trust \cite{sas2016design}. The decentralized blockchain gives users a sense of honestly and credibility contrasted to sometimes dishonest central financial institutions. Users value transparency in the public ledger as well as easy, quick, and low cost transactions. Unregulated Bitcoin gives users a sense of empowerment, setting no limits to transaction frequency and size, and comfort in the impossibility of governmental intervening with financial matters in the system.
On the other hand, surveyed users showed concern over insecure transactions and risks associated with literally managing their own finances which were categorized by the authors as:
\begin{itemize}
\item \textit{Risks Due to Users' Challenges of Handling Passwords} (or private keys)
\item \textit{Risks Due to Hackers' Malicious Attacks} to steal coins
\item \textit{Risks Due to Failure to Recover from Human Error or Malice}
\item \textit{Risks Related to Dishonest Partner of Transaction}
\end{itemize}
These risks are heightened by hackers benefiting from irreversibility of transactions, lack of regulation, and pseudo-anonymity. Also highlighted by Ali, Clarke, and McCorry, \textit{``Denoting money as virtual assets to remove reliance on banks also opens the doors to hackers and malware.''}\cite{Ali:2015:BPU:2990603.2990632}. The same factors increase the severity of losses due to user error, such as a forgotten password, wrong receiver account address, or incorrect amount in a transaction. Off chain components of transactions, such as the exchange of fiat currency for Bitcoin or buying goods and services, have no component on the blockchain and hence have possibility for fraud and deception.
The authors propose strategies for mitigating the risks of dishonest traders, the main aspect of user distrust in transacting with Bitcoin:
\begin{itemize}
\item \textit{Trade with Authorized Exchanges}
\item \textit{Trade with Socially Authorized Traders}
\item \textit{Trade with Reputable Individual Traders}
\item \textit{Trade with De-anonymised Individual Traders}
\item \textit{Regulating Bitcoin}
\end{itemize}
These propositions to mitigate risks paradoxically nullify some key privacy and decentralized features of Bitcoin. Users are more likely to trust the counter-party when they are socially validated and/or identified and no longer anonymous, a type of user and community driven KYC to build trust. Exchanges add an interface to the traditional financial institution, forcing users to undergo traditional AML and KYC processes. Regulating Bitcoin completely goes against the original vision of Nakamoto, but could help users deal with dishonest traders and bring the security and institutional trust of regulated financial institutions, which is currently best served by exchanges.
The authors propose three general design implications for Bitcoin to \textit{``address the trust challenges of dishonest traders while respecting blockchain's main characteristics''}\cite{sas2016design}:
\begin{itemize}
\item \textit{Support Transparency of Two-way Transactions} (on and off blockchain)
\item \textit{Create Tools for Materializing Trust in Blockchain}
\item \textit{Create Tools to Support Reversible Transactions}
\end{itemize}
The study highlights the trust needs of usable digital currency and motivates the creation of Euro 2.0 system.
\subsection{Ethereum} \label{ssec:2:ethereum}
Ethereum generalizes blockchain technology as a decentralized computing platform for building distributed applications. Ethereum is used to implement the decentralized component of Euro 2.0, providing the main account balance and state data and functionality described in \hypersectionref{ssec:3.4}. \hypersectionref{sssec:2:ethereum:platform} gives an overview of the necessary details of the Ethereum platform and \hypersectionref{sssec:2:ethereum:soliditySmartContracts} outlines the key points of the Solidity Smart Contracts programming language used later in the thesis.
\subsubsection{Ethereum Platform} \label{sssec:2:ethereum:platform}
The core of Ethereum is the \textit{Ethereum Virtual Machine} (EVM), which functions as a decentralized general purpose computing platform with Turning complete scripting functionality. Ethereum is formally specified in Wood's \textit{Ethereum: A Secure Decentralised Generalised Transaction Ledger}\cite{yellowpaper}, also know as the ``Yellowpaper'' functioning as a ``technical bible'' of the Ethereum platform. The Yellowpaper, although very detailed and thorough, is too low level of a formal specification to be digestible as an introduction to the platform. Buterin's Ethereum Whitepaper, \textit{A Next-Generation Smart Contract and Decentralized Application Platform}\cite{whitepaper}, is a high level introduction to the platform suitable for understanding the key decentralized concepts of Euro 2.0. Anderson et al. compare Namecoin, Peercoin, and Ethereum to Bitcoin, looking at factors such as blockchain disk size and client bootstrapping security, and present the results of a crawler on the Ethereum blockchain looking at contract usages and Zombie contracts\cite{Anderson2016NewKO}.
\paragraph*{Accounts}
Ethereum state is held in objects called \textit{accounts}. An account is composed of the following fields:
\begin{itemize}
\item \textit{nonce} - a counter used to make sure each transaction can only be processed once
\item \textit{balance} - amount of Ether in the account
\item \textit{contract code} - the code associated with this account, if present
\item \textit{storage} - storage space for this account
\end{itemize}
An Ethereum account is named with a 20 byte address. This address is the \code{Keccak-256} hash of a public key of a private generated from an Elliptic Curve Digital Signature Algorithm. Accounts come in two flavors: \textit{Externally Controlled Accounts} and \textit{Contract Accounts}. Externally controlled accounts are controlled by private keys of users outside of Ethereum and can be used to send messages by creating and signing transactions. Contract account code is executed upon a received messages to the address. This executed code can read and write to local storage, send other messages, and also create contracts. Both types of accounts store a balance of \textit{Ether}, the currency of Ethereum, which can be used as a store of value and as fee for miners to execute EVM code. Ether is produced by miners as an output of producing blocks in a Proof-of-Work mechanism. Unlike bitcoin, Ether doesn't have a capped total supply, but is anticipated to be produced at the same rate of Ether being lost to unaccessible accounts where the private key is lost or unknown.
\paragraph*{Messages and Transactions}
Messages and transactions in Ethereum are the same construct. A \textit{Transaction} refers to a signed message from an externally owned Ethereum account with the following fields:
\begin{itemize}
\item Recipient Ethereum address of the message
\item Signature identifying the sender
\item Amount of Ether transferred from the sender to the recipient
\item Optional data field accessible by smart contract
\item \code{STARTGAS} value in Ether, the maximum amount of fee a given transaction is allowed to execute
\item \code{GASPRICE} value in Ether, the fee the sender pays per computational step
\end{itemize}
Transactions are persisted on the blockchain. Account code will be executed upon receipt of a message. Gas allows for a Turing complete scripting language by creating economical disincentive for accidental or intentional denial of service attacks through infinite loops or expensive computations. Each computational step has a fee in a multiple of \code{GASPRICE} and when greater or equal to transaction specified \code{STARTGAS} has been executed, the computation fails with all execution changes rollback. Blocks of transactions also have a dynamic gas limit to the total computational expense of an entire block of transactions.
Messages refer to those originating from a contract \code{CALL} opcode and not by an external actor. These are not persisted on the blockchain and are only virtual objects in the Ethereum execution environment of nodes on the network. Messages contain the following fields:
\begin{itemize}
\item Sender Ethereum address of the message
\item Recipient Ethereum address of the message
\item Amount of Ether to transfer with the message
\item Optional data field
\item \code{STARTGAS} value in Ether delegated to the message from calling contract original gas
\end{itemize}
Limited top level \code{STARTGAS} prevents contracts from calling in infinite recursive loops.
\paragraph*{Ethereum State Transition Function}
Unlike Bitcoin's unspent transaction output (\textit{UTXO}) mechanism, Ethereum employs an account model of system state. The Ethereum state $S$ represents the state of all addresses, balances, contracts, and data in the Ethereum. Given a transaction $TX$ the new Ethereum state $S'$ is computed by the state transaction function $APPLY(S,TX) -> S'$ and does the following according to the Ethereum Whitepaper\cite{whitepaper}:
\begin{itemize}
\item Check if transaction is valid, signature is valid, and nonce matches sender account nonce; if not throw an error.
\item Calculate transaction fee as \code{STARTGAS * GASPRICE}, determine the sending address from the signature, subtract the fee from the sender's account balance, and increments the sender's nonce. If there is not enough balance, throw an error.
\item Initialize \code{GAS = STARTGAS}, and take off a certain quantity of gas per byte to pay for the bytes in the transaction.
\item Transfer the transaction value from the sender's account to the receiving account. If the receiving account does not yet exist, it is created. If the receiving account is a contract, run the contract's code either to completion or until the execution runs out of gas.
\item If the value transfer failed because the sender had insufficient balance or the code execution ran out of gas, revert all state changes except the payment of the fees, and add the fees to the miner's account.
\item Otherwise, refund the fees for all remaining gas to the sender, and send the gas fees consumed to the miner.
\end{itemize}
State is calculated and stored identically on every node in the network for all transactions.
\paragraph*{Ethereum Code}
Ethereum code is fundamentally a low-level, stack-based, byte code language referred to as the ``EVM code''. Distributed applications in Ethereum are usually written in high level languages such as python based Serpent\cite{serpent} or javascript based Solidity, which is described in \hypersectionref{sssec:2:ethereum:soliditySmartContracts}, and then compiled to EVM bytecode. Code executes until an error is thrown, runs out of gas, or a \code{STOP} or \code{RETURN} statement is executed. Persistence capabilities include a last-in-first-out (LIFO) \textit{stack} in which values can be pushed and popped, an infinitely expandable byte array \textit{memory}, or contract \textit{storage}, a key value store which persists after computation has finished (unlike the memory or stack). Executing code also has access to the value, sender, and data of an incoming message and can return a byte array of data as an output.
\paragraph*{Events}
Events are a space optimized, searchable, storage of predefined conditions in contracts described formally in the Yellowpaper\cite{yellowpaper}. This is analogous to logs in the traditional computing. These logs are not usable like contract storage in future Ethereum computations, but provide searchable records of the past usable in Ethereum applications.
\paragraph*{Blockchain and Mining}
Ethereum has a proof-of-work mining mechanism, like Bitcoin, to economically incentivize miner nodes to maintain the global state of Ethereum network for Ether rewards. Miners compete to solve a cryptographic puzzle to produce valid blocks of transactions. The hash of the previous block is an input to a new block, hence forming a blockchain record of transactions. In the process of mining, the block validation process executes the EVM code for all contracts involved in transactions. This implies that all EVM code is being executed simultaneously by all nodes in the network and all contract data is public and shared on the network. Blocks are mined in Ethereum at an average rate of ten to fifteen seconds unlike, the rate of ten minutes of Bitcoin. The security of the network lies in the difficulty of producing valid blocks, with valid cryptographic proof-of-work puzzle, and valid state transition faster than new blocks of honest nodes.
\subsubsection{Solidity Smart Contracts} \label{sssec:2:ethereum:soliditySmartContracts}
Solidity is a high level programming languages to define Smart Contracts for the Ethereum Virtual Machines\cite{solidity}. It has syntax is similar to Javascript, statically typed, supports inheritance, libraries, and many other features. A high level overview of a very small subset of features of Solidity needed to understand the smart contracts discussed in this thesis are described below.
\paragraph*{Contract Structure}
A minimal viable Solidity Smart contract is defined below in the \code{contract.sol} file below:
\begin{lstlisting}
pragma solidity ^0.4.10;
contract ContractName {
...
}
\end{lstlisting}
\code{pragma} declares the version of solidity. \code{contract} indicates a contract with ContractName. Contract is synonymous to class in most object oriented programming languages. Inside the contract definition can be any number of \textit{data} fields, \textit{functions}, \textit{modifiers}, and \textit{events} described below.
\paragraph*{Data}
Data in Solidity smart contracts are like fields in other object oriented languages. They have the basic structure of \code{<type> <visibility> <name>}. Example types are listed below:
\begin{itemize}
\item \code{address} - a 20 byte value of an Ethereum address
\item \code{uint256} - an unsigned 256 bit integer
\item \code{bool} - boolean
\item \code{bytes32} - fixed sized byte array of 32 bytes
\item \code{\_ArrayType[]} - represents a dynamically sized array of \code{\_ArrayType}
\item \code{mapping(\_KeyType => \_ValueType)} - a dynamically sized mapping (hash table) with quite a few Ethereum specific intricacies not listed below. There is no size function, nested mappings are prohibited, and mappings cannot be iterated.
\end{itemize}
Visibility choices are listed below:
\begin{itemize}
\item \code{public} - automatic getter function is generated
\item \code{internal} - can only be accessed internally to current contract or contracts inheriting from the current
\item \code{private} - only visible to current contract and no inherited contracts
\end{itemize}
Because smart contracts are deployed on the blockchain \textbf{all data is stored on every node of the Ethereum network} whether it's ``public'' or ``private''. Hence secrets can only be saved with encrypted or hashed data.
\paragraph*{Functions}
Functions headers are defined in a contract with the following structure:
\lstset{basicstyle=\scriptsize}
\begin{lstlisting}
function name(<parameters>) {internal|external} [modifier] [returns (<return types>)]
\end{lstlisting}
\code{name} is the name of the function. \code{<parameters>} are the parameters of the function such as \code{(address source, uint256 amount)}. \code{internal} function can only be used in the current contract while \code{external} function can be called from messages directly to the deployed contract. \code{returns} is optional and specifies the function's single or multiple \code{(<return types>)}. \code{modifier} is described in the next section.
A function body can have some implicit values accessible in functions, such as \code{msg.sender} which is the sender address of the message or transaction calling the function or \code{msg.value}, the amount of Ether sent with the message.
\paragraph*{Modifiers}
A modifier is a special block of code to add validation or assertion logic to a function. For example,
\lstset{basicstyle=\small}
\begin{lstlisting}
address public masterAccount;
modifier onlyMasterAccount {
if(msg.sender != masterAccount) throw;
_ ;
}
\end{lstlisting}
can be used in a function like,
\lstset{basicstyle=\scriptsize}
\begin{lstlisting}
function appointMasterAccount(address next) onlyMasterAccount { masterAccount = next; }
\end{lstlisting}
to restrict \code{appointMasterAccount} to only a caller transactions whose sender is an address \code{masterAccount} (meaning the transaction was signed by master account's private key) otherwise the function executes \code{throw}. \code{throw} is a very important command in the Solidity programming language, throwing an exception, reverting all execution, and forfeiting all gas to the miner. Contract functions typically have many many modifiers and/or validation logic to throw an exception for unexpected input.
\paragraph*{Events}
Events are the last major construct used in this thesis. An event is a sort of structured log message that is later searchable in the Ethereum blockchain. For example, inside a function could have the event defined:
\lstset{basicstyle=\scriptsize}
\begin{lstlisting}
event Transfer(address indexed source, address indexed destination, uint256 amount)
\end{lstlisting}
which can be executed in a function by calling \code{Transfer(source, destination, amount)}. This creates a log entry in the Ethereum blockchain that could be searched for a particular \code{source} and \code{destination} address.
\subsection{Estonia ID Card} \label{ssec:2:estoniaIdCard}
Estonian ID Card and Mobile ID is used to identity users in the the Euro 2.0 digital currency system. The detailed architecture of the ID card system is not considered in the security analysis presented in this thesis. Martens summarizes the development of the national electronic Identity Management System (eIDMS), describing its technical features, its historical development, and the contributions from the public and private sector\cite{Martens2010electronicIdentity}. Springall et al. perform a security analysis of Estonian internet voting scheme and in their introduction provide an overview of the Estonian national ID card infrastructure \cite{estoniaInternetVoting}.
The central agency of the Estonia ID card system is the Estonia Citizenship and Migration Board (CMB), under the authority of the Ministry of Interior, with the responsibility of maintaining the population register, administering national Personal Identification Codes (PIC), and issuing identity documents. The 11 digit PIC has the following structure:
\begin{itemize}
\item digit for gender and century of the birth (one digit for two attributes)
\item date of birth digits (YY+MM+DD)
\item three random digits
\item one checksum digit
\end{itemize}
The Estonian ID card contains two electronic RSA key pair certificates, one for authentication and one for legally binding signatures regulated under the Estonian Digital Signatures Act and administered by SK Certification Center\cite{aboutSk2017}. The card also has an unprotected data file containing the personal information displayed on the physical card. Public key certificates are stored in a public LDAP database administered by SK\cite{skAboutLdap2017}. Certificates require a pin code for use. Both certificates and card have a validity of five years for citizens or length of validity of legal residence if less than five years. Mobile ID is offered by carriers through a special PKI-capable SIM card and allows the same functionality as the ID card through a mobile interface. Estonia ID card or Mobile ID TLS authentication is widely used in online banking in the country. A user sends an authentication requests, enters his pin code, and if the certificate is still valid, is authenticated to the website.
\subsection{Information Security Risk Analysis Frameworks} \label{ssec:2:issrmFramework}
Information System Security Risk Management (ISSRM) is a broad field with \textit{``over 200 practitioner-oriented risk management methods and several academic security modeling frameworks available"}\cite{Dubois2010}. From these, we need to choose an appropriate framework to guide our security risk analysis of the Euro 2.0 digital currency prototype in \hyperchapterref{sec:5}. Duboi et al. build a unified domain model of ISSRM by surveying and categorizing risk management standards, information security and information technology standards, risk management methodologies, and security frameworks, as well as the state of the art of security modeling languages. This serves as a useful source of representative security risk analysis frameworks to choose from.
Ahmed and Matulevi\v{c}ius explore eliciting security requirements earlier in business process modeling by introducing security risk oriented patterns\cite{Ahmed:2014:SBP:2588915.2589308}. The goal is to \textit{``align business processes and security requirements elicited using security risk-oriented patterns''} to mitigate security risks. This gives a good contextual framework for thinking through a security analysis on business processes.
Uzunov and Fernandez give a deeply technical overview of security patterns of distributed systems\cite{Uzunov:2014:EPL:2588915.2589309}. They first survey threat patterns, pattern-based threat taxonomies, and architectural contexts for the threat patterns. Then they provide a list first level security threat patterns and second level meta-security threat patterns to see further analysis. Then they construct a specialized taxonomy of security threats for distributed and peer to peer systems. The ideas presented are useful input for the Euro 2.0. security risk analysis in \hypersectionref{sec:5}.
From the review of various security risk analysis frameworks, \textit{OCTAVE Allegro} was chosen as the simplest framework allowing a strait forward risk analysis of the Euro 2.0 proccesses using a seven step methodology\cite{CaralliIntroducingOCTAVE2007}:
\begin{itemize}
\item \textit{Step 1 - Establish Risk Measurement Criteria}
\item \textit{Step 2 - Develop an Information Asset Profile}
\item \textit{Step 3 - Identify Information Asset Containers}
\item \textit{Step 4 - Identify Areas of Concern}
\item \textit{Step 5 - Identify Threat Scenarios}
\item \textit{Step 6 - Identify Risks}
\item \textit{Step 7 - Analyze Risks}
\item \textit{Step 8 - Select Mitigation Approach}
\end{itemize}
We use inspiration from security patterns of from the other two papers as input for the OCTAVE Allegro risk analysis. We chose not to undergo formal modeling or complicated modeling software, as complexity explodes when applied to a complicated system like Euro 2.0, without any benefits of the time invested.
\pagebreak
\section{Euro 2.0 Digital Currency Prototype} \label{sec:3}
\subsection{Introduction} \label{ssec:3.1}
This chapter introduces the Euro 2.0 digital currency system. The contents of this section are based from a prototype developed by the Euro 2.0 Foundation as a non profit initiative. The code is accessible in Github under the MIT License as indicated in \hyperref[ssec:a.1]{Appendix A.1}. The chapter explores the following research question:
\begin{quoting}
\textbf{RQ1:} \textit{How do we describe the features and components of the Euro 2.0 digital currency system for a security analysis?}
\end{quoting}
Which is broken down into the following sub-questions:
\begin{quoting}
\textbf{RQ1.1: }\textit{What are the features of the Euro 2.0 digital currency?}
\end{quoting}{
\begin{quoting}
\textbf{RQ1.2: }\textit{What are the decentralized components?}
\end{quoting}{
\begin{quoting}
\textbf{RQ1.3: }\textit{What are the centralized components?}
\end{quoting}
\begin{quoting}
\textbf{RQ1.4: }\textit{How do the decentralized and centralized work together to fulfill the features?}
\end{quoting}
Answering \textit{RQ1} lays the groundwork for further analysis in \hypernameref{sec:4} and \hypernameref{sec:5}. \hypersectionref{ssec:3.2} will briefly go through the motivation behind the Euro 2.0 digital currency system. \hypersectionref{ssec:3.3} will give an overview of the system architecture and features currently implemented answering \textit{RQ1.1}. \hypersectionref{ssec:3.4} will give an overview of the decentralized components built on the Ethereum platform answering \textit{RQ1.2}. \hypersectionref{ssec:3.5} will give an overview of centralized components built with traditional software development architecture answering \textit{RQ1.3}. Finally \hypersectionref{ssec:3.6} will briefly describe how the centralized and decentralized components work together to fulfill the features answering \textit{RQ1.4}.
\subsection{Euro 2.0 Motivation} \label{ssec:3.2}
The idea of Euro 2.0 originated in 2014 from Kristo Käärmann's blogpost \textit{Government Backed Bitcoin}\cite{kaarmann2014government}. Following the success of Bitcoin, he saw an opportunity for a payments settled on a Government backed cryptocurrency, \textit{EuroCoin}, pegged one to one to real world Euro counterpart. Paypal cofounder Max Levchin supports the same idea, \textit{``I am confident that there will be a form of settlement that will be a crypto-currency''}\cite{pando2014levchin}. Bitcoin's short term fluctuations, functioning both as a commodity and a currency, in value make it unreasonable for end to end holdings in a fiat based economy. Removing financial intermediaries in payments reduces the costs of transactions.
Even some governments have expressed interests in digital currency. The Swedish central bank debated whether to become the first to issue digital currency as a response to the country's move away from cash\cite{milne2016sweden}. The UK government pushed for a ``Call for Information'' on digital currencies in order to assess risks\cite{nermin2014ukcall} that was later responded by Citi bank's global Treasury and Trade Services (TTS) Technology and Innovation Team with a suggestion for government to create its own digital currency\cite{spaven2015ukcurrency}:
\begin{quoting}
\textit{``The greatest benefits of digital currencies can be realized through the government issuing a digital form of legal tender. This currency would be less expensive, more efficient and provide greater transparency than current physical legal tender or electronic methods.''}
\end{quoting}
Following the rise in popularity of Ethereum, in mid 2016, another blogpost by Käärmann \textit{The future of money may be in the ether}\cite{kaarmann2016ether} described the rough idea of the system. We can describe Euro 2.0 as attempting to solve the business problem:
\begin{quoting}
\textit{How do I build a system to digitally store and transact fiat currency without a centralized for-profit financial intermediary conveniently, trustfully, and securely while satisfying government regulations?}
\end{quoting}
From this business problem derives the key pillars of Euro 2.0:
\begin{enumerate}
\item Fiat backed
\item Decentralized accounts and transactions
\item Identities of all users
\item Convenient conversion between fiat and digital assets
\item Government can control monetary supply
\item Features for law enforcement and AML
\end{enumerate}
\textit{Fiat backed} (1) provides monetary stability to the system and builds trust with users and merchants to keep assets in the digital format. This eliminates the issue of constantly fluctuating daily value between real world and digital assets seen in crypto currencies today.
\textit{Decentralized accounts and transactions} (2) comes from the need of an impeccable record and process of transacting value that no centralised party can modify in a database. This is the key benefit and usecase of distributed ledger technology.
\textit{Identities of all users} (3) builds trust in the system for users, merchants, and governments. If everyone is identified, any transaction can be legally ramified (assuming legislation arises supporting distributed ledger records in the court). The strong identity of Estonian ID card is a perfect fit for a digitally identifying mechanism and the main driver of the first prototype.
\textit{Convenient conversion between fiat and digital assets} (4) makes it easy for users to gradually start using the digital currency from existing financial infrastructure. At first this exchange gateway can be a private financial institution, similar to Tether\cite{tether}, with a proof of reserve of the one to one Euro backing. Ideally this conversion service is hosted by the central bank itself to limit the number of financial intermediaries.
\textit{Government can control monetary supply} (5) follows from the ideal scenario of (4), the central bank can issue new money directly into the digital monetary system without a real world Euro counterpart.
\textit{Features for law enforcement and AML} (6) is the most controversial aspect of the system. Bitcoin was made to sidestep the direct control of any third party, including government\cite{nakamoto2008bitcoin}. Euro 2.0 needs to be regulated from the start with full support of governments, which requires necessary intervention that typically happen today via cooperation with regulated financial institutions.
\subsection{Euro 2.0 Features} \label{ssec:3.3}
The following section describes the main features of the Euro 2.0 system. Features are enumerated with the label \textbf{XY\#} where:
\begin{itemize}
\item \textbf{X} is an abbreviation of the domain of the feature, described in the \hypernameref{sssec:3.3:domains} section
\item \textbf{Y} is client, admin, or server. Client is a user of the system, admin is some superuser with special permissions, and server is some centralized or decentralized server infrastructure
\item \textbf{\#} is the number of a feature for a given \textbf{XY}
\end{itemize}
Features are implemented with a combination of decentralized and centralized components described in \hypersectionref{ssec:3.4} and \hypersectionref{ssec:3.5} respectively.
\subsubsection{Domains} \label{sssec:3.3:domains}
\hypertableref{tab:domains} gives an overview of the domains of Euro 2.0 used to group features described in later sections.
\begin{center}
\begin{tabular}{ | l | c | p{10cm} | }
\hline
Domain & Abbr. & Description \\
\hline
\textbf{Account} & A & Mechanism of storage of value in the system
\\ \hline
\textbf{Identity} & I & Features linking real life human identity to users
\\ \hline
\textbf{Transaction} & T & Mechanism of transfer of value in the system
\\ \hline
\textbf{Reserve} & R & Features regarding the exchange of value between traditional Euro (EUR) in the financial system and digital Euro (EUR2)
\\ \hline
\textbf{Enforcement} & E & Features for government regulators and law enforcement to police the system for misuse and AML
\\ \hline
\textbf{Convenience} & C & Features for improving user experience and expanding use cases
\\ \hline
\end{tabular}
\end{center}
\captionof{table}{Domains of Euro 2.0}
\label{tab:domains}
\subsubsection{Entities} \label{sssec:3.3:entities}
\hypertableref{tab:entities} clarifies key data entities used throughout the description of features.
\begin{center}
\begin{tabular}{ | p{3cm} | p{12cm} | }
\hline
Entity & Description
\\ \hline\hline
Address & Ethereum externally controlled address (i.e. public key) holding EUR2 and Ether
\\ \hline
Key & Ethereum address private key needed to make transactions (EUR2 or Ether) for an address
\\ \hline
Account & All verified Ethereum addresses for an ID
\\ \hline
Account Balance & Sum of total balance of EUR2 in an account
\\ \hline
ID & Estonian ID code of an individual (citizen, resident, e-resident)
\\ \hline
ID Name & Name of person associated with an Estonian ID Code
\\ \hline
EUR & Euro currency in an Estonian bank account
\\ \hline
EUR2 & Euro currency in the Euro 2.0 digital form, balance of an address in the Euro 2.0 Ethereum contract
\\ \hline
Wallet & Client program (app or mobile web) used as an interface to Euro 2.0 system, accessible keys to addresses
\\ \hline
Wallet Password & Password used to encrypt and decrypt local wallet
\\ \hline
Backup Password & Password used to encrypt and decrypt keys and address to send to backup server
\\ \hline
Designator account & Account collecting seized funds
\\ \hline
\end{tabular}
\end{center}
\captionof{table}{Euro 2.0 Entities}
\label{tab:entities}
\subsubsection{Roles} \label{sssec:3.3:roles}
\begin{center}
\begin{tabular}{ | p{3cm} | p{12cm} | }
\hline
Role & Description
\\ \hline\hline
CryptoFiat Master & Ethereum address (public / private key) to master contract
\\ \hline
Approver & Ethereum address (public / private key) entitled to approver operations
\\ \hline
Reserve Bank & Ethereum address (public / private key) entitled to reserve operations and funds
\\ \hline
Enforcer & Ethereum address (public / private key) entitled to to enforcer operations
\\ \hline
Designator & Ethereum address (public / private key) entitled to designator operations
\\ \hline
\end{tabular}
\end{center}
\captionof{table}{Euro 2.0 Roles}
\label{tab:roles}
\subsubsection{Processes} \label{sssec:3.3:processes}
\hypertableref{tab:processes} clarifies different processes used throughout the description of features.
\begin{center}
\begin{tabular}{ | p{3cm} | p{12cm} | }
\hline
Process & Description
\\ \hline\hline
Approval & Link Ethereum address with the an Estonian ID number via ID card certificate verification. Allow Ethereum address to send EUR2.
\\ \hline
Freeze & Stop address from sending EUR2.
\\ \hline
Close & Stop address from receiving EUR2.
\\ \hline
Seize & Remove EUR2 from an address and send them to the designator account.
\\ \hline
AML checks & AML database lookup based on real name of person.
\\ \hline
\end{tabular}
\end{center}
\captionof{table}{Euro 2.0 Processes}
\label{tab:processes}
\subsubsection{Account Features} \label{sssec:3.3:accounts}
Client
\begin{itemize}
\item \textbf{AC1} - Create address
\item \textbf{AC2} - View account balance
\end{itemize}
Server
\begin{itemize}
\item \textbf{AS1} - Aggregate account balance
\end{itemize}
The account features allow users of store balance of EUR2. The requirement is an Ethereum public and private key pair created in \textbf{AC1}. Viewing account balance is taking the sum of all addresses under ownership of the user's private keys. A server aggregation is needed for retrieving the balances and resolving delegated balances described later.
\subsubsection{Identity Features} \label{sssec:3.3:identity}
Client
\begin{itemize}
\item \textbf{IC1} - Approve address
\end{itemize}
Server
\begin{itemize}
\item \textbf{IS1} - Check external source for valid ID
\item \textbf{IS2} - Approve address
\item \textbf{IS3} - Save ID number to address mapping
\item \textbf{IS4} - Look up Ethereum address by ID
\end{itemize}
In order for an address to transact EUR2, it needs to be approved, that is linked with an identity. The server here plays a critical role in approving the address by checking a client approval request (\textbf{IC1}) with an external source (\textbf{IS1}) then both approving this address on the blockchain (\textbf{IS2}) and saving this mapping (\textbf{IS3}) for use in other components (\textbf{IS4}).
\subsubsection{Transaction Features} \label{sssec:3.3:transactions}
Client
\begin{itemize}
\item \textbf{TC1} - Send EUR2 to an address
\item \textbf{TC2} - Send EUR2 to an ID
\item \textbf{TC3} - Receive EUR2 to an address
\item \textbf{TC4} - Receive EUR2 to an ID
\item \textbf{TC5} - Send EUR2 to a EUR bank account
\end{itemize}
Server
\begin{itemize}
\item \textbf{TS1} - Resolve ID to an address
\item \textbf{TS2} - Escrow EUR2 to an ID
\item \textbf{TS3} - Release escrow EUR2 to an address for an ID
\item \textbf{TS4} - Execute valid EUR transaction
\item \textbf{TS5} - Execute valid EUR2 transaction
\end{itemize}
The transaction features are the heart of the EUR2 system. What differentiates Euro 2.0 from other cryptocurrencies is the ability to easily send funds amongst digital (EUR2) and real (EUR) Euros. \textbf{TC1} and \textbf{TC3} allow a user to transact EUR2 directly with the Ethereum decentralized system using Ethereum addresses. \textbf{TC2} and \textbf{TC4} allow a user to conveniently send EUR2 to a human being via their ID code using the centralized identity infrastructure (\textbf{IS4}). Funds sent to an ID that does not yet have an Ethereum address will have EUR2 held to a new Ethereum address in Escrow (\textbf{TS2}) and then later released and transferred to an address created and approved by the receiver (\textbf{TS3}). \textbf{TS5} provides the infrastructure to execute EUR2 transactions for \textbf{TC1} through \textbf{TC4}. A centralized party needs to provide the mediation gateway (\textbf{TS4}) allowing a user to send EUR2 to a EUR bank account (\textbf{TC5}).
\subsubsection{Reserve Features} \label{sssec:3.3:reserve}
Client
\begin{itemize}
\item \textbf{RC1} - Convert EUR to EUR2
\item \textbf{RC2} - Convert EUR2 to EUR
\item \textbf{RC3} - Proof of reserve
\end{itemize}
Admin
\begin{itemize}
\item \textbf{RA1} - Assign reserve bank address
\item \textbf{RA2} - Manage reserve bank account
\end{itemize}
Server
\begin{itemize}
\item \textbf{RS1} - Resolve address from ID of received EUR transaction
\item \textbf{RS2} - Create EUR2
\item \textbf{RS3} - Destroy EUR2
\end{itemize}
The reserve features allow convenient conversion between EUR and EUR2. The reserve process for converting from EUR to EUR2 is to to receive a EUR bank transaction with an individuals ID (\textbf{RS1}), create EUR2 (\textbf{RS2}) of the equivalent amount, resolve the ID to an Ethereum address (\textbf{TS1}), and send this to the address for the ID (\textbf{TS5}). Likewise the process from converting EUR2 to EUR is receiving a EUR2 transaction (\textbf{RC1}), destroy the EUR2 (\textbf{RS3}), and send a bank transfer of the equivalent amount in EUR (\textbf{TS4}). Finally there is admin feature to assign the reserve EUR2 address to make conversions (\textbf{RA1}) and actually perform manage the banking operations on the bank account (\textbf{RA2}).
\subsubsection{Enforcement Features} \label{sssec:3.3:enforcement}
Admin
\begin{itemize}
\item \textbf{EA1} - Freeze account
\item \textbf{EA2} - Seize account funds to designator's address, closing the account
\item \textbf{EA3} - Assign enforcement
\item \textbf{EA4} - Assign designator
\item \textbf{EA5} - Set designator address
\item \textbf{EA6} - View name check and analysis data
\end{itemize}
Server
\begin{itemize}
\item \textbf{ES1} - AML checks on ID names
\item \textbf{ES2} - Create database of transactions with ID
\end{itemize}
The enforcement features allow law enforcement to do their job that would be traditionally be done via financial institutions. Law enforcement can freeze (\textbf{EA1}) and seize (\textbf{EA2}) funds to the designator address (\textbf{EA5}). Admin controls exist to assign the role of enforcer (\textbf{EA3}) and designator (\textbf{EA4}). Finally automatic processes in the server need to perform name checks on all users of the system (\textbf{ES1}) and create a database of identities and transactions (\textbf{ES2}) to be usable by some analysts (\textbf{EA6}).
\subsubsection{Convenience Features} \label{sssec:3.3:backup}
The convenience features are not necessarily central to a functioning and compliant fiat and digital monetary system, but are quite useful to increase the usefulness and usability barrier. They are quite important to consider in a security analysis, hence listed here.
\paragraph*{Wallet Security}
Client
\begin{itemize}
\item \textbf{CC1} - Encrypt wallet
\item \textbf{CC2} - Decrypt wallet
\end{itemize}
Since private keys are stored locally on a user's device, they should be encrypted (\textbf{CC1}) with some password when not in use and decrypted (\textbf{CC2}) when needed for signing transactions.
\paragraph*{Key Backup}
Client
\begin{itemize}
\item \textbf{CC3} - Encrypt keys for addresses
\item \textbf{CC4} - Create a cryptographic challenge
\item \textbf{CC5} - Send addresses, keys, and challenge to backup server for an ID
\item \textbf{CC6} - Retrieve addresses and keys from backup server for an ID with challenge answer
\item \textbf{CC7} - Decrypt keys for addresses
\end{itemize}
Server
\begin{itemize}
\item \textbf{CS1} - Save encrypted addresses and keys for an ID
\item \textbf{CS2} - Check challenge answer
\item \textbf{CS3} - Load encrypted addresses and keys for an ID
\end{itemize}
Since keys are stored locally, if not backed up, they can be easily lost with the device. Euro 2.0 provides a centralized convenience feature to back up these keys for an ID and secured by a challenge question. The user can encrypt their keys with a password (\textbf{CC3}), create a cryptographic challenge (\textbf{CC4}), send the addresses, encrypted keys, and challenge to the server (\textbf{CC5}) to be saved (\textbf{CS1}). The user can then retrieve the addresses and encrypted keys for an ID from the server (\textbf{CC6}) by providing the correct challenge answer checked by the server (\textbf{CS2}) (\textbf{CS3}), and finally the keys can be decrypted by the user (\textbf{CC7}).
\paragraph*{Transfer Details}
Client
\begin{itemize}
\item \textbf{CC8} - Encrypt copies of transfer details for sender and receiver
\item \textbf{CC9} - Save transfer details for a transaction hash
\item \textbf{CC10} - Load transfer details for a transaction hash
\item \textbf{CC11} - Decrypt transfer details for sender or recipient
\end{itemize}
Server
\begin{itemize}
\item \textbf{CS4} - Save transfer details for a transaction hash
\item \textbf{CS5} - Load transfer details for a transaction hash
\end{itemize}
Transfer details features provide extra information to transfers only visible to sender and receiver. First a sender of a transaction encrypts two copies of the transfer details, one with the sender's public key and the other with the recipient's private key (\textbf{CC8}). Then these can be saved to the transfer details server with the transaction's hash (\textbf{CC9} and \textbf{CS4}). Then these details can be loaded from the server (\textbf{CS5}) by the sender or receiver from the server (\textbf{CC10}) and decrypted with their respective private key (\textbf{CC11}).
\paragraph*{Account Recovery}
Client
\begin{itemize}
\item \textbf{CC12} - Set address recovery address
\item \textbf{CC13} - Recover address funds
\end{itemize}
Server
\begin{itemize}
\item \textbf{CS6} - Execute address funds recovery transaction and close account
\end{itemize}
Account recovery features offer some protection from accidentally losing keys to an address. A user can set a very trusted address, a friend or close relative, with the able to recover funds (\textbf{CC12}). This trusted party at any time can perform the funds recovery and withdraw all of the account's funds to their account with their key (\textbf{CC13}) executed by the server (\textbf{CS6}).
\paragraph*{Delegated Transfers - Send without Ether}
Client
\begin{itemize}
\item \textbf{CC13} - Execute EUR2 transaction with a EUR2 fee instead of Ether for gas
\end{itemize}
\begin{itemize}
\item \textbf{CS7} - Fulfill delegated EUR2 transaction and claim EUR2 fee
\end{itemize}
Finally, this convenience feature eliminates the side effect of using Ethereum, consuming gas (ether) in transactions. A trusted third party, the wallet server in this case, can execute transactions on behalf of the sender (\textbf{CC13}) and take the fee in EUR2 cents instead of Ether (\textbf{CS7}). This requires only the trusted third party to have Ether and the user can only worry about EUR2.
\subsection{Decentralized Components} \label{ssec:3.4}
This section walks through the decentralized components of the Euro 2.0 system on the Ethereum distributed application platform. The main container of code deployment is the \textit{Contract}. Once deployed, the contract is on the blockchain forever processing received transactions and messages, unless an optional destroy function is implemented and called. All function calls and data modifications are irreversible and publicly visible while being executed on the thousands of computers on the Ethereum network maintaining the Ethereum blockchain. Thus we describe the implementation of the Euro 2.0 contracts in detail, since this non-revertible code is important for security considerations.
The decentralized contracts are comprised of of the main administrator contract (\textit{CryptoFiat}), shared contracts (\textit{Constants}, \textit{Relay}, \textit{Data}, \textit{InternalData}), and the upgradable subcontracts providing functionality to the system (\textit{Accounts}, \textit{Approving}, \textit{Reserve}, \textit{Enforcement}, \textit{AccountRecovery}, \textit{Delegation}). The contract code can be found in \hyperref[ssec:a.2]{Appendix A:2}. These decentralized contracts function as gateways to the shared decentralized data of the Euro 2.0 system used together with centralized components of \hypersectionref{ssec:3.5} to fulfill the features of the system in \hypersectionref{ssec:3.6}.
\todo[inline]{Diagram with inheritance structure of all contracts}
\subsubsection{CryptoFiat Contract} \label{sssec:3.4:cryptofiat}
The heart of decentralized Euro 2.0 is the \textit{CryptoFiat} contract. This contract functions as an administrator, managing the master address and the references to all deployed contracts comprising the main functionality of the Euro 2.0 system.
\begin{center}
\resizebox{\textwidth}{!}{
\begin{tabular}{ | l | l | p{9cm} | }
\hline
Name & Type & Description
\\ \hline\hline
\code{masterAccount} & \code{address} & Master Ethereum account whose allowed to do operations on the CryptoFiat contract. Set in the constructor and changeable by master account owner.
\\ \hline
\code{contractAddress} & \code{uint256 => address} & Stores mapping from subcontract id to deployed address of active subcontract.
\\ \hline
\code{contractId} & \code{address => uint256} & Stores mapping from active subcontract address to id.
\\ \hline
\code{contracts} & \code{address[]} & Array with the address of all contracts ever added to the Euro 2.0 system. It's contents is never cleared.
\\ \hline
\end{tabular}}
\end{center}
\captionof{table}{CryptoFiat contract data}
\label{tab:cryptoFiatData}
\begin{center}
\resizebox{\textwidth}{!}{
\begin{tabular}{ | l | l | p{9cm} | }
\hline
Function & Args & Description
\\ \hline\hline
\code{contractActive} & \code{address addr} & Returns \code{bool} whether the subcontract at address \code{addr} is active.
\\ \hline
\code{contractsLength} & & Returns the length of \code{contracts}, i.e. the number of all contracts ever deployed.
\\ \hline
\code{appointMasterAccount} & \code{address next} & Sets \code{masterAccount} to \code{next} and hence gives up control of the CryptoFiat contract. Can only be called by master account owner.
\\ \hline
\code{upgrade} & \specialcell{\code{uint256 id}\\ \code{address next}} & Upgrades the active contract with \code{id} to the address \code{next}. Only owner of master account can call this. \code{prev} cannot be the same contract as \code{next}. \code{next} cannot be an already active contract. \code{contractAddress}, \code{contractId}, and \code{contracts} are updated appropriately.
\\ \hline
\end{tabular}}
\end{center}
\captionof{table}{CryptoFiat contract functions}
\label{tab:cryptoFiatFunctions}
\begin{center}