[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-cashless2ecash] branch master updated: docs: save commit
|
From: |
gnunet |
|
Subject: |
[taler-cashless2ecash] branch master updated: docs: save commit |
|
Date: |
Wed, 29 May 2024 07:53:02 +0200 |
This is an automated email from the git hooks/post-receive script.
joel-haeberli pushed a commit to branch master
in repository cashless2ecash.
The following commit(s) were added to refs/heads/master by this push:
new 70277d3 docs: save commit
70277d3 is described below
commit 70277d3870b20d788ea08cb62b0b88c3cb28b1cb
Author: Joel-Haeberli <haebu@rubigen.ch>
AuthorDate: Wed May 29 07:52:46 2024 +0200
docs: save commit
---
docs/content/acknowledgements.tex | 2 +-
docs/content/implementation/e-security.tex | 125 ++++++++++++++++++++++++++++-
docs/content/implementation/f-cli.tex | 4 +-
docs/content/results/discussion.tex | 5 +-
docs/content/results/reflexion.tex | 14 +++-
docs/project.bib | 16 +++-
docs/thesis.pdf | Bin 1768000 -> 1803553 bytes
7 files changed, 157 insertions(+), 9 deletions(-)
diff --git a/docs/content/acknowledgements.tex
b/docs/content/acknowledgements.tex
index 978865a..63e3a1c 100644
--- a/docs/content/acknowledgements.tex
+++ b/docs/content/acknowledgements.tex
@@ -4,6 +4,6 @@ The GNU Taler team deserves a big thank you to discuss, reflect
and sharpen the
Also I thank my colleagues from the class who motivated me during thesis.
Especially I would like to thank Jan Fuhrer for the nice friday night coding
sessions, Christian Blättler for the valuable discussion about Taler and Andy
Bigler for the exchange about Android applications. They were crucial to gain a
better understanding of how the components work and how I must do the
implementation.
-Additionally I would like to thank Meret Staub for her critical eyes and
thoughts during the proofreading of the thesis.
+Additionally I would like to thank Meret Staub for her critical thoughts
during the proofreading of the thesis.
Last but not least I thank Flurina from all my heart. You were not mad at me
when I had to cancel dinner, because I wanted to write some code.
diff --git a/docs/content/implementation/e-security.tex
b/docs/content/implementation/e-security.tex
index 7530e61..d55b85d 100644
--- a/docs/content/implementation/e-security.tex
+++ b/docs/content/implementation/e-security.tex
@@ -1,5 +1,128 @@
\section{Security}
+\subsection{Threat Model}
+
+The four question framework motivated by the OWASP threat modelling project
\cite{owasp-threat-modeling-project} was leveraged to identify threats and
discuss what to do about them.
+
+\subsubsection{Scope}
+
+The scope of the model includes the C2EC component as well as the Terminal
application. Out of scope are the Exchange, Wallet, CLI and the payment system
provider backend. The scope is set to only those two components, because they
are the only one implemented during the thesis.
+
+\subsubsection{Identification of threats}
+
+To identify threats in a methodological way the STRIDE method
\cite{owasp-threat-modeling-stride} to identify threats was applied.
+
+\begin{itemize}
+ \item \textbf{S}poofing:
+ \begin{itemize}
+ \item Terminal gets stolen and with it its credentials (A).
+ \item Attacker can imitate the payment system provider backend (B).
+ \end{itemize}
+ \item \textbf{T}ampering:
+ \begin{itemize}
+ \item Abort withdrawals...
+ \begin{enumerate}
+ \item by reading a WOPID from the URL (C)
+ \item by guessing the WOPID (D)
+ \end{enumerate}
+ \item Trigger confirmation requests with stolen terminal. (E)
+ \item Poisoning the provider configuration. (F)
+ \end{itemize}
+ \item \textbf{R}epudiation:
+ \begin{itemize}
+ \item Same terminal credentials for more than one terminal. (G)
+ \end{itemize}
+ \item \textbf{I}nformation Disclosure:
+ \begin{itemize}
+ \item URL discloses WOPID (H)
+ \item Weak passwords (I)
+ \end{itemize}
+ \item \textbf{D}enial of Service:
+ \begin{itemize}
+ \item Use unauthenticated Bank-Integration API to generate heavy load
on the server. (J)
+ \item Trigger the withdrawal confirmation process through stolen
terminal access tokens. (E)
+ \end{itemize}
+ \item \textbf{E}levation of Privileges:
+ \begin{itemize}
+ \item Bad configuration (K)
+ \item Using the same user for all duties. (L)
+ \item Weak passwords (I)
+ \end{itemize}
+\end{itemize}
+
+\subsubsection{Response and Mitigations}
+
+To define what to do about risks which occur due to the above mentioned
threats an understanding of the impact of the threat need
+
+To understand the impact when a threat is exploited they are assessed and
prioritized for further analysis using following risk assessment scheme:
+
+\begin{center}
+$risk = probability * impact$
+\end{center}
+
+There is no data available. The probability is guessed and motivated. The risk
assessment assumes that a secure platform is used to run the system. This
includes network level preventions of security issues such as ARP- or DNS
poisoning are installed. This means only application level probabilities are
considered. Additionally it is assumed that the operator behaves as the
configuration suggests and leverages a security wise sound process during the
configuration and deployment of C2EC.
+
+Values for \textbf{probability} (P) are motivated because of the following
categories:
+\begin{itemize}
+ \item 1: The event will occur less than once a year.
+ \item 2: The event will occur on a monthly base.
+ \item 3: The event will occur on a daily base.
+\end{itemize}
+
+Values for the \textbf{impact} (I) are motivated through the following table:
+\begin{itemize}
+ \item 1: The exploitation will have no cost effects for the Exchange
operator.
+ \item 2: The exploitation will lead to manual expense and therefore costs.
+ \item 3: The exploitation will lead to loss of money.
+\end{itemize}
+
+% table: probability, impact, risk, description
+
+\begin{table}[H]
+ \centering
+ \caption{Risk assessment}
+ \label{sec-implementation-security-risk}
+
\begin{tabularx}{\textwidth}{p{0.1\textwidth}|p{0.1\textwidth}|p{0.1\textwidth}|p{0.1\textwidth}|p{0.4\textwidth}}
+ \hline
+ \textbf{Id} & \textbf{P} & \textbf{I} & \textbf{Risk} &
\textbf{Description} \\
+ \hline
+ A & 3 & 1 & 3 & \\
+ \hline
+ B & 1 & 3 & 3 & \\
+ \hline
+ C & 3 & 2 & 6 & \\
+ \hline
+ D & 1 & 2 & 2 & \\
+ \hline
+ E & 3 & 1 & 3 & \\
+ \hline
+ F & 1 & 3 & 3 & \\
+ \hline
+ G & 2 & 1 & 2 & \\
+ \hline
+ H & 3 & 2 & 6 & \\
+ \hline
+ I & 1 & 3 & 3 & \\
+ \hline
+ J & 3 & 2 & 6 & \\
+ \hline
+ K & 1 & 3 & 3 & \\
+ \hline
+ L & 2 & 1 & 2 & \\
+ \hline
+ \end{tabularx}
+\end{table}
+
+\subsubsection{Review and Validation}
+
+To review and validate the threat model, two cases were reviewed. The first
mirrors the easiest attack (EAV eavesdropping and abusing WOPID). The second
case reviews where the most harm can be possibly be done to the system.
+
+Case 1:
+
+
+Case 2:
+This case is possible, when an attacker can trick the C2EC to have confirmed
withdrawals in its withdrawal table, without having a real confirmation of the
payment service provider. This means the attacker can steal money from the
exchange. For this an attacker would need to have the possibility to somehow
trick the confirmation process of C2EC to issue confirmation requestes against
a backend controlled by the attacker. This backend would then confirm the
withdrawal. This will lead to t [...]
+
\subsection{Withdrawal Operation Identifier (WOPID)}
\label{sec-security-wopid}
@@ -22,7 +145,7 @@ The database user executing a database query must have
enough rights to execute
\centering
\caption{Database users}
\label{sec-implementation-security-database-users}
-
\begin{tabularx}{\textwidth}{|p{0.2\textwidth}|p{0.2\textwidth}|p{0.6\textwidth}|}
+
\begin{tabularx}{\textwidth}{p{0.2\textwidth}|p{0.2\textwidth}|p{0.5\textwidth}}
\hline
\textbf{Username} & \textbf{Component} & \textbf{Description} \\
\hline
diff --git a/docs/content/implementation/f-cli.tex
b/docs/content/implementation/f-cli.tex
index e0ac713..8a4b40a 100644
--- a/docs/content/implementation/f-cli.tex
+++ b/docs/content/implementation/f-cli.tex
@@ -3,11 +3,11 @@
The management of providers and terminals is not part of the thesis but since
writing and issueing SQL statements is cumbersome and error-prone a small cli
was implemented to abstract managment tasks. The cli tool was also shows the
concepts a future implementation of the provider managment can use to integrate
with the present features. The cli can be extended with more actions to allow
the management of other providers and its terminals. Also the cli allows to
setup the simulation term [...]
-The cli was implemented to be usable and as it was out of scope of the thesis,
the focus was on the functionality and tasks needed for the thesis and to allow
an easy management of the terminals. This included features to manage wallee
provider and terminals and the simulation. Additionally the tool implements
commands to activate and deactivate a terminal, which makes the task much
easier than writing and executing SQL by hand. Also it eliminates mistakes by
reducing problems to bugs in [...]
+The cli was implemented to be usable and as it was out of scope of the thesis,
the focus was on the functionality and tasks needed for the thesis and to allow
an easy management of the terminals. This included features to manage wallee
provider and terminals and the simulation. Additionally the tool implements
commands to activate and deactivate a terminal, which makes the task much
easier than writing and executing SQL by hand.
\subsection{Adding a Wallee provider}
-Adding the Wallee provider is as easy as calling \textit{rp}
(register-provider). It will then ask for properties like the base url and the
credentials of the API user. Since the payto target type in case of Wallee will
always be \textit{wallee-transaction}, this is hard coded. The credentials
supplied are encrypted using argon2 and stored as hash. Like this if the
database leaks for some reason the credentials are still not easy to crack,
when no standard password was used. Since Wallee [...]
+Adding the Wallee provider is as easy as calling \textit{rp}
(register-provider). It will then ask for properties like the base url and the
credentials of the API user (generated by Wallee). Since the payto target type
in case of Wallee will always be \textit{wallee-transaction}, this is hard
coded. The credentials supplied are encrypted using argon2 and stored as hash.
If the database leaks for some reason, the passwords cannot be abused easily.
\subsection{Adding a terminal}
diff --git a/docs/content/results/discussion.tex
b/docs/content/results/discussion.tex
index e6b04f9..6aea8e1 100644
--- a/docs/content/results/discussion.tex
+++ b/docs/content/results/discussion.tex
@@ -2,7 +2,7 @@
Our work shows that withdrawals in GNU Taler are possible using the payment
service provider Wallee. The C2EC implementation shows how the process can be
implemented and integrated into the rest of the Taler ecosystem.
-The design of the Terminals API was a major field of work during the process.
Only after a few iterations, the specification was ready. The iterations were
necessary to sharpen the understanding of how the terminal and C2EC must
interact and integrate with the existing Taler components in order to make the
withdrawals functional.
+The design of the Terminals API was a major field of work during the process.
Only after several iterations, the specification was ready. The iterations were
necessary to sharpen the understanding of how the terminal and C2EC must
interact and integrate with the existing Taler components in order to make the
withdrawals functional.
The implementation of the existing Bank-Integration and Wire-Gateway API were
a challenge because they must be implemented with great care to not violate the
specification. Another challenging task was the design of C2EC. To create a
useful, robust and extensible design other components of Taler must have been
understood. This task was a little more time consuming than initially planned.
I thought at first that I would understand how to implement C2EC and then just
simply do it. In reali [...]
@@ -10,6 +10,8 @@ A challenge which was encountered during the implementation
of the terminal appl
Towards the end of the implementation it became obvious that a simple
authorization was not enough to imitate the real time feeling of the
withdrawal. Other Requests were necessary to do so. To findout which requests
needed to be filed against the Wallee backend some investigation had to be
made. The documentation does explain which states exists in Wallee's
transaction scheme but it does not explain, which operation do trigger the
transition of one state to another. This made the invest [...]
+For the analysis of the security of the system I was happy to find STRIDE
which gave me some boundaries and guided me through the process. I found it
hard to identify real threats and not loosing time about threats which were out
of scope. In the end I think the solution is quite secure in terms of money. Of
course you can steal terminals and wreck the nerves of the terminal operators
but you won't be able to somehow manipulate the payment process which will
allow you to
+
\section{Future Work}
C2EC introduces new ways to access digital cash using GNU Taler. Due to the
short time available during the thesis, features and integrations are missing
which can make it even more valuable. Because of this I provide a list of
future work. Maybe there are other students or collaborators who want to join
in and add their features to the existing code. The list might not be complete
and any new ideas are appreciated. I splitted the list into the list of
extensions and improvements.
@@ -30,4 +32,5 @@ C2EC introduces new ways to access digital cash using GNU
Taler. Due to the shor
\item C2EC: Remove doubled provider structures. Currently providers are
saved to the database and must be configured in the configuration. To make the
setup and management easier, the providers could only be configured inside the
configuration.
\item App: Automatically trigger long poll request for parameter
selection. Due to the lack of time, the long-poll request for the parameter
selection on the side of the terminal was not implemented to be automatically
but will only be sent, when the user clicks on the \textit{authorize} button.
The request shall be triggered in the background instead.
\item The Wallee-Transaction payto target type is currently abused and not
implemented in conformance of the specification in the GANA. To resolve this
issue, the Wallee-Transaction identifier needs to be saved alongside the
merchant reference which is currently used for the lookup of the transaction.
+ \item IPv6 support: The process must also listen on IPv6 addresses.
\end{enumerate}
diff --git a/docs/content/results/reflexion.tex
b/docs/content/results/reflexion.tex
index 89eee7c..52eb79c 100644
--- a/docs/content/results/reflexion.tex
+++ b/docs/content/results/reflexion.tex
@@ -1,4 +1,4 @@
-\section{Reflexion}
+\section{Reflection}
\subsection{Technically}
@@ -12,12 +12,20 @@ In Go code of the C2EC component I had to implement a
robust way to communicate
Concerning the extensibility of C2EC I was able to implement nice code level
abstractions which allow an easy integration of additional payment system
providers. After the feedback of Prof. Dr. Christian Grothoff I was able to
eliminate an unnecessary layer of abstraction, which makes it even easier.
+I think I could apply a lot of knowledge I gained through the past three
years. It happened a lot that I was thinking: "ah, this is why the professor
told us this". This helped me to harden my understanding of various topics.
+
\subsubsection{Paydroid Terminal Application}
-The paydroid application was challenging to me since I never wrote a real
Android application on my own. Therefore I think I did a good job by
implementing a best practice structure with the view models, composable and
navigation controller. Through the feedback of Prof. Dr. Benjamin Fehrensen I
was able to verify the correctness of these best practices. I first had
problems to understand how exactly the versioning in Android works and that the
backward compatibility is given even in big [...]
+The paydroid application was challenging to me since I never wrote a real
Android application on my own. Therefore I think I did a good job by
implementing a best practice structure with the view models, composable and
navigation controller. Through the feedback of Prof. Dr. Benjamin Fehrensen I
was able to verify the correctness of these best practices.
+
+I first had problems to understand how exactly the versioning in Android works
and that the backward compatibility is given even when big time gaps between
the feature needed and the version I was big. In the beginning I suffered a
little to understand the difference of the none compose and compose era of
Android programming.
+
+Since the app needs to do stuff in the background I had to understand how this
could be achieved. Therefore I needed to understand how I can access other
threads. I think in this area is the biggest shortcoming of my implementation.
I failed to implement a proper asynchronous state-handling. Threads running
detached from the UI-Thread will update the model, which will lead to the
regeneration of the composables. I think it would be a better way to implement
a proper pub / sub model using [...]
\subsection{Methodically}
-\subsection{Personally}
\ No newline at end of file
+\subsection{Personally}
+
+
diff --git a/docs/project.bib b/docs/project.bib
index 7c83e37..90bb57c 100644
--- a/docs/project.bib
+++ b/docs/project.bib
@@ -391,4 +391,18 @@
title = {Password Hashing Competition},
url = {https://www.password-hashing.net},
howpublished = {\url{https://www.password-hashing.net}},
-}
\ No newline at end of file
+}
+
+@misc{owasp-threat-modeling-project,
+ author = {OWASP Threat Modeling Project},
+ title = {OWASP Threat Modeling Project},
+ url = {https://owasp.org/www-project-threat-model/},
+ howpublished = {\url{https://owasp.org/www-project-threat-model/}},
+}
+
+@misc{owasp-threat-modeling-stride,
+ author = {OWASP Cheat Sheet Series},
+ title = {Threat Identification},
+ url =
{https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html#threat-identification},
+ howpublished =
{\url{https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html#threat-identification}},
+}
diff --git a/docs/thesis.pdf b/docs/thesis.pdf
index 5227685..864e1d2 100644
Binary files a/docs/thesis.pdf and b/docs/thesis.pdf differ
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.