e-cli.tex (3837B)
1 \section{C2EC CLI} 2 \label{sec-implementation-cli} 3 4 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 or by starting the cli with the \textit{-c} option with the path to the \textit{.ini} config file containing the connection string. 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. 5 6 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 a simple 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. 7 8 \subsection{Adding Wallee Provider} 9 10 Adding the Wallee provider can be achieved 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. 11 12 \subsection{Adding Wallee Terminal} 13 14 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 '-') 15 16 \subsection{Deactivating Terminals} 17 18 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. 19 20 \subsection{Setting Up The Simulation} 21 22 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.