commit 8103cce7a0467906d8a3e2f07667d3eb5e609578
parent 454a09a97fe81fc935248ac3481b1d80167d3d5a
Author: Joel-Haeberli <haebu@rubigen.ch>
Date: Thu, 30 May 2024 13:24:36 +0200
save commit
Diffstat:
12 files changed, 146 insertions(+), 135 deletions(-)
diff --git a/c2ec/wallee-client.go b/c2ec/wallee-client.go
@@ -197,7 +197,7 @@ func (w *WalleeClient) Refund(transactionId string) error {
Transaction: WalleeRefundTransaction{
Id: int64(decodedWalleeTransaction.Id),
},
- Type: "",
+ Type: "MERCHANT_INITIATED_ONLINE", // this type will refund the transaction using the responsible processor (e.g. VISA, MasterCard, TWINT, etc.)
}
_, status, err := HttpPost[WalleeRefund, any](url, hdrs, refund, NewJsonCodec[WalleeRefund](), nil)
diff --git a/cli/go.mod b/cli/go.mod
@@ -5,6 +5,7 @@ go 1.22.1
require (
github.com/jackc/pgx/v5 v5.5.5
golang.org/x/crypto v0.22.0
+ gopkg.in/ini.v1 v1.67.0
)
require (
@@ -14,5 +15,4 @@ require (
golang.org/x/sync v0.1.0 // indirect
golang.org/x/sys v0.19.0 // indirect
golang.org/x/text v0.14.0 // indirect
- gopkg.in/ini.v1 v1.67.0 // indirect
)
diff --git a/docs/content/implementation/d-security.tex b/docs/content/implementation/d-security.tex
@@ -0,0 +1,108 @@
+\section{Security}
+
+\subsection{General Security Considerations}
+
+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{EAV abusing WOPID}
+
+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.
+
+The confirmation or abort from the side of the terminal are mitigated through the authentication of the terminals. When the eavesdropping adversary (EAV) \cite{katz2020introduction} 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 would normally use? 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 the 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). What about wallets run by people in countries which are politically not as stable as Switzerland and censorship is a problem? Maybe it's a good idea to add some mean of authentication to at least the abort endpoint of the Bank-Integration API. On the other hand the attacker needs access to the victims phone anyway and could possibly also use the keys.
+
+\subsubsection{Trying to withdraw money without paying}
+
+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.
+
+\subsubsection{Developer issues}
+
+Another problem could be developers introducing confirmation bugs. The confirmation process of a transaction must be considered as the holy grail from the perspective of the developers. If they do not take biggest care implementing the confirmation process, this could lead to loss of money on the side of the Exchange operator. The program should strictly disallow withdrawals, if it is not 100 percent guaranteed by the payment system provider that the state a transaction is in means that the payment effectively went through and is settled. Otherwise the finality is harmed and the system no longer secure.
+
+\subsection{Withdrawal Operation Identifier (WOPID)}
+\label{sec-security-wopid}
+
+The \textit{WOPID} needs great care when generated. When the \textit{WOPID} becomes somehow foreseeable, it opens the door for attackers allowing them to hijack the withdrawal from a remote location or bully the operators by simply aborting any withdrawal. Therefore the \textit{WOPID} needs to leverage high entropy sources to be generated. This is achieved by using the crypto random library of Go. The library is part of the standard library and gains entropy through the entropy sources of the device running the application (in case of linux it is \textit{getrandom(2)} which takes its entropy from \textit{/dev/urandom}, according to the documentation \cite{golang-crypto-rand}).
+
+\subsection{Database Security}
+
+The database is very important as it decides wether to allow a withdrawal or not and it manages terminals and providers which hold sensitive credentials. Therefore two important aspects need to be considered.
+
+\subsubsection{Storing credentials}
+
+Even if a database leak occurs, it shall be very hard for the attacker to access the API using the credentials stored in the database. This is why credentials are stored using the PBKDF \textit{argon2} \cite{password-competition-argon2}. \textit{Argon2} is the winner of the password hashing competition initiated by the cryptographer Jean-Philippe Aumasson \cite{password-competition-argon2}. It is a widely adopted best practice approach for hashing passwords. Storing the hash of the credentials makes abusing stolen credentials very hard and therefore prevents the abuse of credentials gathered through a database leak. The CLI described in \autoref{sec-implementation-cli} implements operations which will register providers and terminals also hashing the credentials using \textit{argon2}.
+
+\subsubsection{Access data through correct user}
+\label{sec-security-db-users}
+
+The database user executing a database query must have enough rights to execute its duties but not more. Therefore different database users are created for different tasks within the database. The described setup and installation process in \autoref{sec-deployment} will automatically generate the users and grant them the correct rights, when the respective variables are specified.
+
+\begin{table}[H]
+ \centering
+ \caption{Database users}
+ \label{sec-implementation-security-database-users}
+ \begin{tabularx}{\textwidth}{p{0.2\textwidth}|p{0.2\textwidth}|p{0.5\textwidth}}
+ \hline
+ \textbf{Username} & \textbf{Component} & \textbf{Description} \\
+ \hline
+ c2ec\_admin & None & This user is possibly never to be used but during maintenance of the database itself (adding database users\, doing backups\, adding and granting users or others) \\
+ \hline
+ c2ec\_api & C2EC & This user has all rights it needs to manage a withdrawal \\
+ \hline
+ c2ec\_operator & CLI & This user shall be used by an operator of the C2EC component to add providers and terminals. It has no access to withdrawals \\
+ \hline
+ \end{tabularx}
+\end{table}
+
+\subsection{Authenticating at the Wallee ReST API}
+\label{sec-security-auth-wallee}
+
+The Wallee API specifies four Wallee specific headers which are used to authenticate against the API. It defines its own authentication standard and flow. The flow builds on a message authentication code (MAC) which is built on a version, user identifier, and a timestamp. For the creation of the MAC the hash based message authentication code (HMAC) SHA-512 is leveraged which takes the so called \textit{application-user-key} (which is basically just an access-token, which the user receives when creating a new API user) as key and the above mentioned properties plus information about the requested http method and the exactly requested path (including request parameters) as message \cite{wallee-api-authentication}. The format of the message is specified like:
+
+\begin{center}
+ \texttt{Version|User-Id|Unix-Timestamp|Http-Method|Path}
+\end{center}
+
+\begin{itemize}
+ \item Version: The version of the algorithm
+ \item User-Id: The user-id of the requesting user
+ \item Unix-Timestamp: A unix timestamp (seconds since 01.01.1970)
+ \item Http-Method: one of \texttt{HEAD}, \texttt{GET}, \texttt{POST}, \texttt{PUT}, \texttt{DELETE}, \texttt{TRACE}, \texttt{CONNECT}
+ \item Path: The path of the requested URL including the query string (if any)
+\end{itemize}
+
+The resulting string must then be UTF-8 encoded according to RFC-3629 \cite{rfc3629}. There are implementations of the mechanism in Java and other languages available. For Go it was implemented during the thesis.
+
+\subsubsection{Wallee User Access rights}
+
+In order for Wallee to successfully authorize the user's requests, the API user must have the corret access rights. The C2EC Wallee API user must be able to access the transaction service for reading transactions and the refund service to write create refunds at the Wallee backend. Therefore following rigths must be assigned to the API user:
+
+\begin{enumerate}
+ \item Refund-service
+ \item Transaction-Service
+\end{enumerate}
+
+These rights can be assigned on Wallee's management interface by creating a role and assigning the rights to it. The role must then be added to the API user. The assignment of the roles must be done for the space context (Three different contexts are available. The relevant context is the space context, since requests are scoped to a space).
+
+\subsection{API access}
+
+\textbf{Terminals API}
+\label{sec-terminal-api-auth}
+
+The terminal API is accessed by terminals and the authentication mechanism is based on a basic auth scheme as specified by RFC-7617 \cite{rfc7617} an specified in the terminals API specification \cite{taler-terminal-api}. Therefore a generated access-token used as password and a username which is generated registering the terminal using the cli explained in \autoref{sec-security-registering-providers} are leveraged. Currently the terminal id and the provider name of the requesting terminal is included in the username part of the basic auth scheme.
+
+\textbf{Bank-Integration API}
+
+The Bank-Integration API is accessed by Wallets and specified to be unauthenticated.
+
+\textbf{Wire-Gateway API}
+
+The wire gateway specifies a basic authentication scheme \cite{taler-wire-gateway-api-authentication} as described in RFC-7617 \cite{rfc7617}. Therefore the C2EC component allows the configuration of a username and password for the exchange. During the request of the exchange at the wire gateway API, the credentials are checked.
+
+\subsection{Registering Providers and Terminals}
+\label{sec-security-registering-providers}
+
+A provider may want to register a new Terminal or maybe even a new provider shall be registered for the exchange. To make this step easier for the exchange operators, a simple cli program (command line interface) was implemented (\autoref{sec-implementation-cli}). The cli will either ask for a password or generate an access token in case of the terminal registration. The credentials are stored has hashes using a PBKDF (password based key derivation function) so that even if the database leaks, the credentials cannot be easily read by an attacker.
+
+\subsection{Deactivating Terminals}
+
+A Terminal can be stolen, hijacked or hacked by malicious actors. Therefore it must be possible to disable a terminal immediately and no longer allow withdrawals using this terminal. Therefore the \textit{active} flag can be set to \textit{false} for a registered terminal. The Terminals-API which processes withdrawals and authenticates terminals, checks that the requesting terminal is active and is allowed to initiate withdrawals. Since the check for the \textit{active} flag must be done for each request of a terminal, the check can be centralized and is implemented as part of the authentication flow. A Wallee terminal can be deactivated using the cli mentioned in \autoref{sec-security-registering-providers}.
diff --git a/docs/content/implementation/d-wallet.tex b/docs/content/implementation/d-wallet.tex
@@ -1 +0,0 @@
-\section{Wallet}
-\ No newline at end of file
diff --git a/docs/content/implementation/e-cli.tex b/docs/content/implementation/e-cli.tex
@@ -0,0 +1,22 @@
+\section{C2EC CLI}
+\label{sec-implementation-cli}
+
+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.
+
+\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 (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 hashed using argon2 \cite{rfc9106}. If the database leaks for some reason, the passwords cannot be abused easily.
+
+\subsection{Adding a terminal}
+
+Adding a Wallee terminal can be achieved by using the \textit{rt} (register-terminal) command. It will ask the user to enter the description of the terminal and will then generate a 32-byte access token using Go's crypto random library which must be supplied to the owner of the terminal through a secure channel with the \textit{terminal-user-id} (which is just the name of the operator and the id of the terminal separated by a dash '-')
+
+\subsection{Deactivating the terminal}
+
+To deactivate the terminal, the command \textit{dt} must be issued. It will ask for the \textit{terminal-user-id} of the terminal and then deactivate the specified terminal. The deactivation will be immediately and therefore helps to increase the security by allowing immediate action, when a terminal is come to be knwon hijacked, stolen or other fraud is detected specific to the terminal. To detect suspicious activity in production appropriate montioring tools could be installed to automatically trigger alarms.
+
+\subsection{Setting up the Simulation}
+
+The Simulation provider and terminal allow to simulate transactions and interactions of the terminal with the API of C2EC. Therefore the command \textit{sim} will setup the needed provider and terminal including the credentials of the simulation terminal, which must be saved and supplied to the operator through a secure channel. These credentials allow to test the Terminals API using the simulation terminal. The simulation client will not be available in productive environments to reduce the attack surface due to unnecessaty features.
diff --git a/docs/content/implementation/e-security.tex b/docs/content/implementation/e-security.tex
@@ -1,104 +0,0 @@
-\section{Security}
-
-\subsection{General Security Considerations}
-
-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{EAV abusing WOPID}
-
-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.
-
-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{}
-
-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}
-
-The \textit{WOPID} is the achiles heel of the withdrawal operation and therefore needs great care when generated. When the \textit{WOPID} becomes somehow foreseeable, it opens the door for attackers allowing them to hijack the withdrawal from a remote location. Therefore the \textit{WOPID} needs to leverage high entropy sources to be generated. This is achieved by using the crypto random library of Go. The library is part of the standard library and gains entropy through the entropy sources of the device running the application (in case of linux it is \textit{getrandom(2)} which takes its entropy from \textit{/dev/urandom}, according to the documentation \cite{golang-crypto-rand}).
-
-\subsection{Database Security}
-
-The database is very important as it decides wether to allow a withdrawal or not and it manages terminals and providers which hold sensitive credentials. Therefore two important aspects need to be considered.
-
-\subsubsection{Storing credentials}
-
-Even if a database leak occurs, it shall be very hard for the attacker to access the API using the credentials stored in the database. This is why credentials are stored using the PBKDF \textit{argon2} \cite{password-competition-argon2}. \textit{Argon2} is the winner of the password hashing competition initiated by the cryptographer Jean-Philippe Aumasson \cite{password-competition-argon2}. It is a widely adopted best practice approach for hashing passwords. Storing the hash of the credentials makes stealing credentials very hard and therefore prevents the abuse of credentials gathered through a database leak. The CLI described in \autoref{sec-implementation-cli} implements operations which will register providers and terminals also hashing the credentials using \textit{argon2}.
-
-\subsubsection{Access data through correct user}
-\label{sec-security-db-users}
-
-The database user executing a database query must have enough rights to execute its duties but not more. Therefore different database users are created for different tasks within the database. The described setup and installation process in \autoref{sec-deployment} will automatically generate the users and grant them the correct rights, when the respective variables are specified.
-
-\begin{table}[H]
- \centering
- \caption{Database users}
- \label{sec-implementation-security-database-users}
- \begin{tabularx}{\textwidth}{p{0.2\textwidth}|p{0.2\textwidth}|p{0.5\textwidth}}
- \hline
- \textbf{Username} & \textbf{Component} & \textbf{Description} \\
- \hline
- c2ec\_admin & None & This user is possibly never to be used but during maintenance of the database itself (adding database users\, doing backups\, adding and granting users or others) \\
- \hline
- c2ec\_api & C2EC & This user has all rights it needs to manage a withdrawal \\
- \hline
- c2ec\_operator & CLI & This user shall be used by an operator of the C2EC component to add providers and terminals. It has no access to withdrawals \\
- \hline
- \end{tabularx}
-\end{table}
-
-\subsection{Authenticating at the Wallee ReST API}
-\label{sec-security-auth-wallee}
-
-The Wallee API specifies four Wallee specific headers which are used to authenticate against the API. It defines its own authentication standard and flow. The flow builds on a message authentication code (MAC) which is built on a version, user identifier, and a timestamp. For the creation of the MAC the hash based message authentication code (HMAC) SHA-512 is leveraged which takes the so called \textit{application-user-key} (which is basically just an access-token, which the user receives when creating a new API user) as key and the above mentioned properties plus information about the requested http method and the exactly requested path (including request parameters) as message \cite{wallee-api-authentication}. The format of the message is specified like:
-
-\begin{center}
- \texttt{Version|User-Id|Unix-Timestamp|Http-Method|Path}
-\end{center}
-
-\begin{itemize}
- \item Version: The version of the algorithm
- \item User-Id: The user-id of the requesting user
- \item Unix-Timestamp: A unix timestamp (seconds since 01.01.1970)
- \item Http-Method: one of \texttt{HEAD}, \texttt{GET}, \texttt{POST}, \texttt{PUT}, \texttt{DELETE}, \texttt{TRACE}, \texttt{CONNECT}
- \item Path: The path of the requested URL including the query string (if any)
-\end{itemize}
-
-The resulting string must then be UTF-8 encoded according to RFC-3629 \cite{rfc3629}.
-
-\subsubsection{Wallee User Access rights}
-
-In order for Wallee to successfully authorize the user's requests, the API user must have the corret access rights. The C2EC Wallee API user must be able to access the transaction service for reading transactions and the refund service to write create refunds at the Wallee backend. Therefore following rigths must be assigned to the API user:
-
-\begin{enumerate}
- \item Refund-service
- \item Transaction-Service
-\end{enumerate}
-
-These rights can be assigned on Wallee's management interface by creating a role and assigning the rights to it. The role must then be added to the API user. The assignment of the roles must be done for the space context (Three different contexts are available. The relevant context is the space context, since requests are scoped to a space).
-
-\subsection{API access}
-
-\textbf{Terminals API}
-\label{sec-terminal-api-auth}
-
-The terminal API is accessed by terminals and the authentication mechanism is based on a basic auth scheme as specified by RFC-7617 \cite{rfc7617} an specified in the terminals API specification \cite{taler-terminal-api}. Therefore a generated access-token used as password and a username which is generated registering the terminal using the cli explained in \autoref{sec-security-registering-providers} are leveraged. Currently the terminal id and the provider name of the requesting terminal is included in the username part of the basic auth scheme.
-
-\textbf{Bank-Integration API}
-
-The Bank-Integration API is accessed by Wallets and specified to be unauthenticated.
-
-\textbf{Wire-Gateway API}
-
-The wire gateway specifies a basic authentication scheme \cite{taler-wire-gateway-api-authentication} as described in RFC-7617 \cite{rfc7617}. Therefore the C2EC component allows the configuration of a username and password for the exchange. During the request of the exchange at the wire gateway API, the credentials are checked.
-
-\subsection{Registering Providers and Terminals}
-\label{sec-security-registering-providers}
-
-A provider may want to register a new Terminal or maybe even a new provider shall be registered for the exchange. To make this step easier for the exchange operators, a simple cli program (command line interface) was implemented (\autoref{sec-implementation-cli}). The cli will either ask for a password or generate an access token in case of the terminal registration. The credentials are stored has hashes using a PBKDF (password based key derivation function) so that even if the database leaks, the credentials cannot be easily read by an attacker.
-
-\subsection{Deactivating Terminals}
-
-A Terminal can be stolen, hijacked or hacked by malicious actors. Therefore it must be possible to disable a terminal immediately and no longer allow withdrawals using this terminal. Therefore the \textit{active} flag can be set to \textit{false} for a registered terminal. The Terminals-API which processes withdrawals and authenticates terminals, checks that the requesting terminal is active and is allowed to initiate withdrawals. Since the check for the \textit{active} flag must be done for each request of a terminal, the check can be centralized and is implemented as part of the authentication flow. A Wallee terminal can be deactivated using the cli mentioned in \autoref{sec-security-registering-providers}.
diff --git a/docs/content/implementation/f-testing.tex b/docs/content/implementation/e-testing.tex
diff --git a/docs/content/implementation/f-cli.tex b/docs/content/implementation/f-cli.tex
@@ -1,22 +0,0 @@
-\section{C2EC CLI}
-\label{sec-implementation-cli}
-
-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.
-
-\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 (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 hashed using argon2 \cite{rfc9106}. If the database leaks for some reason, the passwords cannot be abused easily.
-
-\subsection{Adding a terminal}
-
-Adding a Wallee terminal can be achieved by using the \textit{rt} (register-terminal) command. It will ask the user to enter the description of the terminal and will then generate a 32-byte access token using Go's crypto random library which must be supplied to the owner of the terminal through a secure channel with the \textit{terminal-user-id} (which is just the name of the operator and the id of the terminal separated by a dash '-')
-
-\subsection{Deactivating the terminal}
-
-To deactivate the terminal, the command \textit{dt} must be issued. It will ask for the \textit{terminal-user-id} of the terminal and then deactivate the specified terminal. The deactivation will be immediately and therefore helps to increase the security by allowing immediate action, when a terminal is come to be knwon hijacked, stolen or other fraud is detected specific to the terminal.
-
-\subsection{Setting up the Simulation}
-
-The Simulation provider and terminal allow to simulate transactions and interactions of the terminal with the API of C2EC. Therefore the command \textit{sim} will setup the needed provider and terminal including the credentials of the simulation terminal, which must be saved and supplied to the operator through a secure channel. These credentials allow to test the Terminals API using the simulation terminal. The simulation client will not be available in productive environments to reduce the attack surface due to unnecessaty features.
diff --git a/docs/content/implementation/g-deployment.tex b/docs/content/implementation/f-deployment.tex
diff --git a/docs/project.bib b/docs/project.bib
@@ -43,6 +43,16 @@
}
+@book{katz2020introduction,
+ title={Introduction to Modern Cryptography},
+ author={Katz, J. and Lindell, Y.},
+ isbn={9781351133012},
+ series={Chapman \& Hall/CRC Cryptography and Network Security Series},
+ url={https://books.google.ch/books?id=RsoOEAAAQBAJ},
+ year={2020},
+ publisher={CRC Press}
+}
+
@misc{pci-dss,
author = {PCI Security Standards Council},
title = {PCI Data Security Standard},
diff --git a/docs/thesis.pdf b/docs/thesis.pdf
Binary files differ.
diff --git a/docs/thesis.tex b/docs/thesis.tex
@@ -210,11 +210,10 @@
\input{content/implementation/a-c2ec}
\input{content/implementation/b-terminal}
\input{content/implementation/c-database}
-\input{content/implementation/d-wallet}
-\input{content/implementation/e-security}
-\input{content/implementation/f-cli}
-\input{content/implementation/f-testing}
-\input{content/implementation/g-deployment}
+\input{content/implementation/d-security}
+\input{content/implementation/e-cli}
+\input{content/implementation/e-testing}
+\input{content/implementation/f-deployment}
\chapter{Results}
\input{content/results/discussion}
