[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-cashless2ecash] branch master updated: we need more logs
|
From: |
gnunet |
|
Subject: |
[taler-cashless2ecash] branch master updated: we need more logs |
|
Date: |
Wed, 29 May 2024 16:46:42 +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 31894d1 we need more logs
31894d1 is described below
commit 31894d1714a8de799fa58bed8e35c44bb94aa10a
Author: Joel-Haeberli <haebu@rubigen.ch>
AuthorDate: Wed May 29 16:46:33 2024 +0200
we need more logs
---
c2ec/api-bank-integration.go | 7 +-
c2ec/main.go | 17 ++++
docs/content/implementation/a-c2ec.tex | 6 +-
docs/content/implementation/e-security.tex | 121 ++---------------------------
docs/content/results/discussion.tex | 4 +-
docs/content/results/reflexion.tex | 14 ++--
docs/thesis.pdf | Bin 1803553 -> 1772944 bytes
simulation/c2ec-simulation | Bin 8315978 -> 8315978 bytes
8 files changed, 41 insertions(+), 128 deletions(-)
diff --git a/c2ec/api-bank-integration.go b/c2ec/api-bank-integration.go
index a295790..59625a3 100644
--- 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
index 3edb2ed..860d247 100644
--- 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
index 9a9e8c8..a73b184 100644
--- 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
index d55b85d..dc088dc 100644
--- 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 t [...]
+\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 t [...]
\subsection{Withdrawal Operation Identifier (WOPID)}
diff --git a/docs/content/results/discussion.tex
b/docs/content/results/discussion.tex
index 6aea8e1..cceddc7 100644
--- 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
index 52eb79c..a834384 100644
--- 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 [...]
+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 us [...]
\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 wed [...]
\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 proje [...]
+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
index 864e1d2..fb1a1a7 100644
Binary files a/docs/thesis.pdf and b/docs/thesis.pdf differ
diff --git a/simulation/c2ec-simulation b/simulation/c2ec-simulation
index 1936d74..14a437a 100755
Binary files a/simulation/c2ec-simulation and b/simulation/c2ec-simulation
differ
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [taler-cashless2ecash] branch master updated: we need more logs,
gnunet <=