summaryrefslogtreecommitdiffstats
path: root/notFinishedCode/Report/test.tex.backup
diff options
context:
space:
mode:
Diffstat (limited to 'notFinishedCode/Report/test.tex.backup')
-rw-r--r--notFinishedCode/Report/test.tex.backup58
1 files changed, 52 insertions, 6 deletions
diff --git a/notFinishedCode/Report/test.tex.backup b/notFinishedCode/Report/test.tex.backup
index 61834ed..6cfdbbe 100644
--- a/notFinishedCode/Report/test.tex.backup
+++ b/notFinishedCode/Report/test.tex.backup
@@ -98,20 +98,56 @@ Prof. Dr. Gerhard Schneider\\ \vspace{1\baselineskip} Supervisors: \\ Konrad Mei
% first chapter
\section{Introduction and Motivation} % chapter 1
-\Large In the following report, the authors will try to give you a brief insight into our team project. The goal of our project was to develop a mechanism for automatic testing of our University Telecommunication network. The Telecommunication network of University of Freiburg consists of our own internal: GSM and telephone network systems; GSM redirecting device (if one initiates a call to one of the four external GSM networks, it redirects the calls to: T-mobile, 02, Vodaphone or E-Plus); a SIP gateway for landline calls inside of Germany (sipgate.de) and international calls. Since we did not have access to internal servers, our strategy was to exploit the existing systems and infer the results out of our findings.
+\Large In the following report, the authors will try to give you a brief insight into our team project. The goal of our project was to develop a mechanism for automatic testing of our University Telecommunication network. The Telecommunication network of University of Freiburg consists of: our own internal GSM and telephone network systems; GSM redirecting device (if one initiates a call to one of the four external GSM networks, it redirects the calls to: T-mobile, 02, Vodaphone or E-Plus); a SIP gateway for landline calls inside of Germany (sipgate.de) and international calls. Since we did not have access to internal servers, our strategy was to exploit the existing systems and infer the results out of our findings.
Before we had started working on our project, we had to analyze the overall network to come up with test cases that contain the highest information content. The next step in our procedure was to implement our ideas into a working piece of software.
-Gradually we implemented a bit-by-bit of the final software. Every single implementation was accompanied by testing and validation procedures. At the end we implemented all the ``black-boxes'' into one big piece of software.
+Gradually we implemented a bit-by-bit of the final software. Every single step was accompanied by testing and validation procedures. At the end we connected all the ``black-boxes'' into one big piece of software. We have fulfilled our requests and goals and made a fully working and operable test software. Despite developing a working software, all the way along we thought about the simplicity of the usage of the software. In the following chapters we will describe in more detail our approach and how each subsystem works.
\newpage
\section{Software concept} % chapter 2
\newpage
\section{Introduction} % section 2.1
-\newpage
\subsection{Usage} % subsection 2.1.1
+\newpage
\section{Design}
+\begin{figure}[hb!]
+ \centering
+ \includegraphics[width=130mm]{bb.jpg}
+ \caption[]{BeagleBoard, a linux-on-chip board where our controller software runs the GSM device }
+\end{figure}
\newpage
\section{Protocol}
-\newpage
-\section{Encryption of data}
+
+\begin{figure}[hb!]
+ \centering
+ \includegraphics[width=130mm]{protocolCommunicationHandler.png}
+ \caption[]{Flowchart of the protocol, on the handler side}
+\end{figure}
+
+\begin{figure}[hb!]
+ \centering
+ \includegraphics[width=130mm]{protocolCommunicationcControllerReceiver.png}
+ \caption[]{Flowchart of the protocol, on the controller side for the caller}
+\end{figure}
+
+\begin{figure}[hb!]
+ \centering
+ \includegraphics[width=130mm]{protocolCommunicationcControllerCaller.png}
+ \caption[]{Flowchart of the protocol, on the controller side for the receiver}
+\end{figure}
+
+%\newpage
+\section{Security and safety of the test system}
+\Large Safety and security of the software plays a major role in our project.
+It is of vital importance that only as few as possible people have access to our test system since the resulting data could be exploited to plan an attack
+(e.g. assume the University alarm system uses the SIP gateway to connect to the outside world and to alarm the police, if one knows that the SIP gateway is not working properly, a burglar could plan to rob the University building just at that moment.) Therefore the choice to go Open Source is justified due to the fact that one should know how every single detail of the system works.
+All the time, while we were working on the project, we were made aware of this issue by Denis and Konrad.
+We decided to use asymmetric key cryptography, where each side has two keys (private and public.) In the next sections we will explain in more details how we applied the methods.
+\subsection{Encryption of the communication channels}
+At first we thoought to encrypt the data before sending them but since none of us was an expert on encryption standards the idea was rejected. Alongside the fact that none of us had been an expert in the field of cryptography, we were not experts in the field of internet programming either. One could find maybe a way to disable our server software with various hacking methods (e.g.
+trying to open the port until the system runs out of memory and in our case the system which we used on the server side was a BeagleBoard with ARM architecture running on a single chip TI OMAP processor, refer to the picture on figure 1.)
+We had to eliminate even the slightest possible threat in return for spending more time for debugging the test software system. Despite we were aware of all these facts, we had to choose one of the plenty implemented encryption standards on Linux.
+Denis and Konrad suggested using the SSH Tunneling method. Using the SSH Tunneling method we could hide the real port we use for our socket connection on the other hand we could force the socket to accept only local connections (i.e. from the machine where the handler software was running.)
+The first problem we faced was that SSH required a username and password everytime we created an SSH Tunnel. We solved this problem by copying the public key from our server (where our test software runs) to the BeagleBoard \cite{sshTunnel}.
+This can be performed by executing the following commands in the terminal shell.
\begin{lstlisting}
import subprocess
import string
@@ -127,7 +163,7 @@ class Ping:
tried += 1
#the parameter c 1 means only one ping to be sent, parameter W 3 means how many seconds the time out should be, 3 seconds
ping_cmd = subprocess.Popen(['ping', self.pingAddress, '-c', '1', '-W', '2'], stdout=subprocess.PIPE, stderr=subprocess.STDOUT).communicate()[0]
-
+b
pingAlive = int(string.find(ping_cmd, '1 received'))
unknownHost = int(string.find(ping_cmd, 'unknown host'))
@@ -136,6 +172,13 @@ class Ping:
\end{lstlisting}
\newpage
\section{Web page}
+
+\begin{figure}[hb!]
+ \centering
+ \includegraphics[width=100mm]{resultsImage.png}
+ \caption[]{Result image showing working, defected and not tested subsystems}
+\end{figure}
+
\newpage
\section{Conclusion}
\newpage
@@ -147,6 +190,9 @@ class Ping:
Hypothesis}, preprint (2003), available at
\url{http://www.math.drofnats.edu/riemann.ps}.
+\bibitem{sshTunnel} R. Natarajan, \emph{3 Steps to perform SSH login without password using ssh-keygen \& ssh-copy-id}, accessed on 18.08.2011, available at
+\url{http://www.thegeekstuff.com/2008/11/3-steps-to-perform-ssh-login-without-password-using-ssh-keygen-ssh-copy-id/}.
+
%bibliography end
\end{thebibliography}