commit 31894d1714a8de799fa58bed8e35c44bb94aa10a
parent c5dff4ec42a205df278836e485f6c6878323009d
Author: Joel-Haeberli <haebu@rubigen.ch>
Date: Wed, 29 May 2024 16:46:33 +0200
we need more logs
Diffstat:
8 files changed, 41 insertions(+), 128 deletions(-)
diff --git a/c2ec/api-bank-integration.go b/c2ec/api-bank-integration.go
@@ -181,9 +181,11 @@ func handleWithdrawalStatus(res http.ResponseWriter, req *http.Request) {
} else {
// this means parameter was not given.
// no long polling (simple get)
+ LogInfo("bank-integration-api", "will not start long-polling")
shouldStartLongPoll = false
}
} else {
+ LogInfo("bank-integration-api", "will not start long-polling")
shouldStartLongPoll = false
}
@@ -249,10 +251,13 @@ func handleWithdrawalStatus(res http.ResponseWriter, req *http.Request) {
}
} else {
wthdrl, stat := getWithdrawalOrError(wpd)
+ LogInfo("api-bank-integration", "loaded withdrawal")
if stat != HTTP_OK {
errStat <- stat
} else {
- w <- wthdrl
+ res.Header().Add(CONTENT_TYPE_HEADER, "application/json")
+ res.Write(wthdrl)
+ return
}
}
diff --git a/c2ec/main.go b/c2ec/main.go
@@ -223,21 +223,25 @@ func setupBankIntegrationRoutes(router *http.ServeMux) {
GET+BANK_INTEGRATION_API+BANK_INTEGRATION_CONFIG_PATTERN,
bankIntegrationConfig,
)
+ LogInfo("main", "setup "+GET+BANK_INTEGRATION_API+BANK_INTEGRATION_CONFIG_PATTERN)
router.HandleFunc(
GET+BANK_INTEGRATION_API+WITHDRAWAL_OPERATION_BY_WOPID_PATTERN,
handleWithdrawalStatus,
)
+ LogInfo("main", "setup "+GET+BANK_INTEGRATION_API+WITHDRAWAL_OPERATION_BY_WOPID_PATTERN)
router.HandleFunc(
POST+BANK_INTEGRATION_API+WITHDRAWAL_OPERATION_BY_WOPID_PATTERN,
handleParameterRegistration,
)
+ LogInfo("main", "setup "+POST+BANK_INTEGRATION_API+WITHDRAWAL_OPERATION_BY_WOPID_PATTERN)
router.HandleFunc(
POST+BANK_INTEGRATION_API+WITHDRAWAL_OPERATION_ABORTION_PATTERN,
handleWithdrawalAbort,
)
+ LogInfo("main", "setup "+POST+BANK_INTEGRATION_API+WITHDRAWAL_OPERATION_ABORTION_PATTERN)
}
func setupWireGatewayRoutes(router *http.ServeMux) {
@@ -246,26 +250,31 @@ func setupWireGatewayRoutes(router *http.ServeMux) {
GET+WIRE_GATEWAY_API+WIRE_GATEWAY_CONFIG_PATTERN,
wireGatewayConfig,
)
+ LogInfo("main", "setup "+GET+WIRE_GATEWAY_API+WIRE_GATEWAY_CONFIG_PATTERN)
router.HandleFunc(
POST+WIRE_GATEWAY_API+WIRE_TRANSFER_PATTERN,
transfer,
)
+ LogInfo("main", "setup "+POST+WIRE_GATEWAY_API+WIRE_TRANSFER_PATTERN)
router.HandleFunc(
GET+WIRE_GATEWAY_API+WIRE_HISTORY_INCOMING_PATTERN,
historyIncoming,
)
+ LogInfo("main", "setup "+GET+WIRE_GATEWAY_API+WIRE_HISTORY_INCOMING_PATTERN)
router.HandleFunc(
GET+WIRE_GATEWAY_API+WIRE_HISTORY_OUTGOING_PATTERN,
historyOutgoing,
)
+ LogInfo("main", "setup "+GET+WIRE_GATEWAY_API+WIRE_HISTORY_OUTGOING_PATTERN)
router.HandleFunc(
POST+WIRE_GATEWAY_API+WIRE_ADMIN_ADD_INCOMING_PATTERN,
adminAddIncoming,
)
+ LogInfo("main", "setup "+POST+WIRE_GATEWAY_API+WIRE_ADMIN_ADD_INCOMING_PATTERN)
}
func setupTerminalRoutes(router *http.ServeMux) {
@@ -274,26 +283,31 @@ func setupTerminalRoutes(router *http.ServeMux) {
GET+TERMINAL_API_CONFIG,
handleTerminalConfig,
)
+ LogInfo("main", "setup "+GET+TERMINAL_API_CONFIG)
router.HandleFunc(
POST+TERMINAL_API_REGISTER_WITHDRAWAL,
handleWithdrawalSetup,
)
+ LogInfo("main", "setup "+POST+TERMINAL_API_REGISTER_WITHDRAWAL)
router.HandleFunc(
POST+TERMINAL_API_CHECK_WITHDRAWAL,
handleWithdrawalCheck,
)
+ LogInfo("main", "setup "+POST+TERMINAL_API_CHECK_WITHDRAWAL)
router.HandleFunc(
GET+TERMINAL_API_WITHDRAWAL_STATUS,
handleWithdrawalStatusTerminal,
)
+ LogInfo("main", "setup "+GET+TERMINAL_API_WITHDRAWAL_STATUS)
router.HandleFunc(
DELETE+TERMINAL_API_ABORT_WITHDRAWAL,
handleWithdrawalAbortTerminal,
)
+ LogInfo("main", "setup "+DELETE+TERMINAL_API_ABORT_WITHDRAWAL)
}
func startListening(router *http.ServeMux, errs chan error) {
@@ -304,6 +318,7 @@ func startListening(router *http.ServeMux, errs chan error) {
if CONFIG.Server.UseUnixDomainSocket {
+ LogInfo("main", "using domain sockets")
socket, err := net.Listen("unix", CONFIG.Server.UnixSocketPath)
if err != nil {
panic("failed listening on socket: " + err.Error())
@@ -326,10 +341,12 @@ func startListening(router *http.ServeMux, errs chan error) {
}()
} else {
+ LogInfo("main", "using tcp")
go func() {
server.Addr = fmt.Sprintf("%s:%d", CONFIG.Server.Host, CONFIG.Server.Port)
LogInfo("main", "serving at "+server.Addr)
if err := server.ListenAndServe(); err != nil {
+ LogError("main", err)
errs <- err
}
}()
diff --git a/docs/content/implementation/a-c2ec.tex b/docs/content/implementation/a-c2ec.tex
@@ -37,16 +37,16 @@ Following a short list of events and from whom they are triggered and who listen
\item Payment confirmation request sent to the Bank-Integration API of C2EC.
\begin{itemize}
\item Registered by: Terminal
- \item Listened by: Attestor
+ \item Listened by: Confirmation
\end{itemize}
\item Payment confirmation success will send a withdrawal operation status update event.
\begin{itemize}
- \item Registered by: Attestor
+ \item Registered by: Confirmation
\item Listened by: Consumers (via Bank-Integration-API)
\end{itemize}
\item Payment confirmation failure will trigger a retry event.
\begin{itemize}
- \item Registered by: Attestor
+ \item Registered by: Confirmation
\item Listened by: Retrier
\end{itemize}
\item Transfers which represent refunds in C2EC.
diff --git a/docs/content/implementation/e-security.tex b/docs/content/implementation/e-security.tex
@@ -1,126 +1,17 @@
\section{Security}
-\subsection{Threat Model}
+\subsection{General Security Considerations}
-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}
+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.
-\subsubsection{Review and Validation}
+\subsubsection{EAV abusing WOPID}
-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.
+A WOPID can be abused triggering a confirmation or an abort request at the Terminals API or an abort request at the Bank-Integration API.
-Case 1:
+The first two cases are mitigated through the authentication of the terminals. When the EAV can somehow access the communication between a terminal and C2EC, the WOPID cannot be abused without also breaking the terminals credentials. What if the attacker decides to use the unauthenticated Bank-Integration API the wallet is normally using? The specification does not require some proof that the requester is the wallet. This could lead to tampering of the withdrawals in the time window of the confirmation of the payment. The problem could be mitigated by sending a signed token in the request (the request already is a POST request). The wallet could use its reserve private key to sign a token. The Bank-Integration API could then verify the token using the reserve public key assigned to the withdrawal operation. It is understandable that the risk is accepted, since a potential adversary would need to be sophisticated (needs to redirect requests of the wallet and read WOPID from the request). But when we think of wallets run by people in countries which are politically not as stable as Switzerland and censorship is a real problem, this might be problem. With a simple signature, this threat could be mitigated.
+\subsubsection{}
-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)}
diff --git a/docs/content/results/discussion.tex b/docs/content/results/discussion.tex
@@ -28,9 +28,7 @@ C2EC introduces new ways to access digital cash using GNU Taler. Due to the shor
\subsection{Improvements}
\begin{enumerate}
\item Run the existing implementation as part of the BFH Taler CHF-Exchange
- \item Approve Paydroid app: Let Wallee check the terminal app and run it on a Wallee terminal on behalf of the BFH.
+ \item Paydroid app: Run a Wallee terminal on behalf of the BFH.
\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
@@ -10,22 +10,24 @@ The implementation of C2EC was the biggest part of my work during the thesis. It
In Go code of the C2EC component I had to implement a robust way to communicate between parallel running processes. Go's concurrency model made this possible in an easy and what I think, comprehensible way. I correctly anticipated that it would pay out to first implement the concepts for my requirements in a dummy project and then adapt this to C2EC. Additionally the implementation of the database access layer behind an interface allows to change the database easily.
-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.
+Concerning the extensibility of C2EC I was able to implement code level abstractions which allow an easy integration of additional payment system providers. After the feedback of Prof. Dr. Christian Grothoff I was could 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.
+I think I could apply a lot of knowledge I gained through the past three years. From time to time 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.
+The paydroid application was challenging to me since I never wrote a real Android application on my own. That's why 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.
+I first had problems to understand how exactly the versioning in Android works. The backward compatibility is given even when big time gaps between the feature needed and the version in use occur. In the beginning I suffered a little to understand the difference of the none compose and compose era of Android programming and mixed the patterns. In the end I think I implemented a modern Android app.
-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.
+Since the app needs to do requests 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}
-
+To organize the work I did a rough planning of the work and the artefacts. On top of this plan I did a weekly iterative planning of the work I wanted to do. This plan was presented through the weekly meeting with Prof. Dr. Christian Grothoff and Prof. Dr. Benjamin Fehrensen. Sometimes the plan needed to be sligthly adjusted due to their feedback. This led to the organization of doing my planning at thursday night so I could plan my work and adjust the plan after our weekly meeting at wednesday morning. I think I could have made the process a bit more transparent but in the end I was able to deliver the artefacts and deliverables on time.
\subsection{Personally}
+The thesis was constrained with a lot of insecurities for me. How does the process look? How can I implement the process? How does GNU Taler even work? How does Wallee work? In the end I am proud of what I accomplished during the thesis. I was able to understand the API and write a program which fulfills the properties needed for the withdrawal. Additionally I could learn a lot about designing an API. I am thankful that the Bern University of Applied Sciences supports free software projects like GNU Taler. It was a great opportunity for me as student to gain direct insights and work on a GNU project during my thesis. I remember that Prof. Dr. Christian Grothoff during a onsite session told me: "Nicht so kurzfristig denken!". This also shows the horizon of the project. It tries to sustainably change the payment lanscape. That is what I like the most about free software. It is built to last.
+The world of payment systems seems a bit chaotic to me. I think this is the result of a lot of different approaches developed at the same time for the same problem. There are standards but they mainly suggest things and do not enforce them. The technical documentation is obfuscated in big documents with a lot of boiler plate text. This makes it very hard to do the correct thing from my point of view.
diff --git a/docs/thesis.pdf b/docs/thesis.pdf
Binary files differ.
diff --git a/simulation/c2ec-simulation b/simulation/c2ec-simulation
Binary files differ.
