commit 70277d3870b20d788ea08cb62b0b88c3cb28b1cb
parent 6819f346a3c78f107e6fad2256295978f7b39276
Author: Joel-Haeberli <haebu@rubigen.ch>
Date: Wed, 29 May 2024 07:52:46 +0200
docs: save commit
Diffstat:
7 files changed, 157 insertions(+), 11 deletions(-)
diff --git 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
@@ -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 the creation of the reserve on the side of the Exchange.
+
\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
@@ -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 terminal and provider which can be used for testing. Before commands can be executed, the user must connect the tool to the database which can be done throught the \textit{db} command. With the aim to not introduce security risks by storing configuration state of the cli, the credentials must be entered after each startup of the cli. This can be surpassed by specifying postgres specific environment variables \texttt{PGHOST}, \texttt{PGPORT}, \texttt{PGUSER} and \texttt{PGPASSWORD} but remember that these environment variables might leak database credentials to others if not cleaned properly or set for the wrong users shell.
-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 implementation of the cli.
+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 generates those access tokens for their API user, this can be assumed to be the case.
+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
@@ -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 reality the process was iterative. Only after a lot of iterations I was able to find a suitable way for the implementation.
@@ -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 investigation somewhat cumbersome. Also the integration of the backend needed more investigation than I thought.
+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
@@ -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 time gaps. 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 a library like rxjs or similar. Due to the lack of time I decided to not do this anymore.
+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 a library like rxjs or similar. Due to the lack of time I decided to not do this anymore.
\subsection{Methodically}
-\subsection{Personally}
-\ No newline at end of file
+\subsection{Personally}
+
+
diff --git 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
Binary files differ.
