\chapter{Technische Umsetzung}
\section {Verbindungsaufbau}
Zwischen dem Bankserver und dem Bankautomaten soll eine Netzwerkverbindung aufgebaut werden. Da Java als Programmiersprache verwendet wird, soll genauer gesagt eine Verbindung zwischen zwei Java Virtual Machines aufgebaut werden. Am naheliegendsten verwendet man hierbei für die Datenübertragung eine Socketverbindung über TCP/IP, welche auch in der Java Welt große Unterstützung findet.\par
Eine Socketverbindung lässt sich mit Java eigenen Mitteln von Grund auf selber programmieren. Jedoch beherbergt diese Variante eine große Fehleranfälligkeit bei der Programmierung. Input- und Outputstreams sind von Hand zu lesen und zu schreiben. Dabei ist der Einsatz von eigens programmierten Threads, welche auf ankommende Nachrichten warten, unabdinglich. Da alleine diese Entwicklung bereits fehleranfällig sein kann, ist es naheliegend ein bereits bestehendes Java Framework zu verwenden, welches etabliert und getestet ist. Hierbei wurde sich das für das RMI-Framework entschieden. Dieses wird im nächsten Abschnitt beschrieben.
\subsection{RMI - Remote Method Invocation}
RMI verfolgt primär zwei Ziele: Zum einen versucht es ein Objekt oder eine Methode aus einer fremden Virtual Machine so aussehen zu lassen, als würde es sich auf der eigenen Virtual Machine befinden, zum anderen soll die Netzwerkarchitektur von dem eigentlichen Projekt gekapselt, dem ausführenden Java Object verborgen bleiben und auch dem Programmierer die Arbeit erleichtern. Abbildung 3.1 verdeutlicht die Architektur.\par
\begin{figure}[htb]
\begin{minipage}[b]{1.0\linewidth}
  \centering
 %\centerline{\epsfig{figure=rmi.jpg,width=8.5cm}}
\centerline{\includegraphics[width=120mm]{pics/rmi.jpg}}
%  \vspace{2.0cm}
\end{minipage}
\caption{RMI Architektur vgl.\cite{Kruger2004}}
\label{fig:rmiarch}
\end{figure}
Die Abbildung lässt erkennen, dass die Netzwerkverbindung und die Verbindungssemantik (Remote Reference Layer) von den eigentlichen Client -und Serverklassen gekapselt sind. Der Client erhält vom Server ein Proxyobjekt, den sogenannten Stub, welcher ein Stellvertreter der tatsächlichen Serverimplementierung (Skeleton) ist. So ruft der Client Methoden/Funktionen auf seinem Stub auf, ohne zu wissen, dass die eigentliche Funktionalität auf dem Server liegt und im Hintergund die Netzwerklogik für ihn gemanaged wird.\par
Um RMI schließlich in einer Java Applikation nutzen zu können, braucht es einen Verweise auf die eigene Policy Datei, welche u.a. wichtige Befugnisse für Socket Verbindung (IP-Filter) beinhaltet.
\lstinputlisting[language=Java]{sources/policyimport.txt}
Eine Policy Datei hat u.a. folgenden Aufbau.
\lstinputlisting[language=Java]{sources/server.policy}
In diesem Beispiel werden sämtliche Verbindungen (*) erlaubt. Im Produktiveinsatz sollten hierbei IP-Whitelists verwendet werden.\par
Wird eine Firewall verwendet, müssen zudem die Ports 1098 und 1099 für RMI geöffnet werden. \cite{RMI}
\subsection{Authentifizierung über SSL}
RMI bietet von Haus aus die Möglichkeit, zwischen den Kommunikationspartnern eine Verbindung über SSL aufzubauen. Hierbei wird die sogenannte SslRMIClientSocketFactory verwendet, welche sich ideal dazu nutzen lässt, Authentifizierung (per Handshake) über Zertifikate einzuführen. Des Weiteren sichert SSL schließlich den aufgebauten Kommunikationskanal mittels einer hybriden Verschlüsselung (RSA + AES).\par


\section {Schlüsselgenerierung}
In der Java Welt herrscht eine eigene Nomenklatur für die Schlüsselcontainer. Man spricht von  "`KeysStores"' und  "`TrustStores"', welche sich jeweils auf dem Server und dem Client befinden. KeyStores beinhalten einmal ihre eigenen geheimen privaten Schlüssel und zudem die Zertifikate, welche später an die Partner verteilt werden. In einem KeyStore können beliebig viele Schlüssel gespeichert werden. TrustStores beinhalten die öffentlichen Schlüssel sowie die Zertifikate der Kommunikationspartner. Am Beispiel der SSL Authentifizierung würde der Client zuerst das vom Server empfangene Zertifikat gegenüber seinem TrustStore verifizieren, um sicherzustellen, dass er mit dem richtigen Partner kommuniziert.
\subsection{Java Keytool}
Dieses Kapitel beschäftigt sich mit der Erzeugung von Public/Private Keys und Zertifikaten. Das Keytool befindet sich im Unterverzeichnis bin des Java Home Ordners. Aufgerufen wird es über die Kommandozeile per keytool.exe mit anknüpfenden Parametern. Folgende Abbildung 3.2 zeigt auf der linken Seite die Befehle für die Generierung eines Zertifikates und auf der rechten Seite das Auslesen des eigenen KeyStores.
\begin{figure}[htb]

 %\centerline{\epsfig{figure=keytool.jpg,width=8.5cm}}
\centerline{\includegraphics[width=120mm]{pics/keytool.jpg}}
%  \vspace{2.0cm}
\caption{Keytool Befehle}
\label{fig:keytool}
\end{figure}
Schließlich muss man der Java Virtual Machine die KeyStores bzw. TrustStores bekannt machen. Dies geht entweder über das Starten der Anwendung per Kommandozeilen-Parameteraufruf oder komfortabler direkt über den Quellcode.\par
Folgender Code ist im Konstruktor der SSL Klasse einzugeben. Einen KeyStore kann man zusätzlich mit einer Passphrase sichern.
\lstinputlisting[language=Java]{sources/keyimport1.txt}
Mit beinahe gleichem Code lässt sich der TrustStore einbinden.
\lstinputlisting[language=Java]{sources/keyimport2.txt}
\section {Sichere Übertragung}
Um auch die einzelnen Datenpakete im Falle einer Kompromittierung des SSL Kanals zu schützen, werde diese gesondert behandelt und abgesichert. Momentan werden Methoden mit ihren Parametern (Kontonummer, Geldbetrag x, Saldo etc..) auf dem Server aufgerufen, welches zur Folge hat, dass diese Werte im Klartext und einzeln übertragen werden. Im Falle einer Analyse des (kompromittierten) Netzwerkverkehrs wären diese offen sichtbar.\par
In Folge dessen werden nicht mehr einzelne Methoden mit Parametern aufgerufen, sondern alle Informationen in eine Hüllklasse zusammengefasst, verschlüsselt und schließlich nur noch über eine(!) öffentliche Servermethode\footnote{Object communicationChannel(Object obj)} übertragen. Diese Hüllklassen nennt man Data Transfer Objects.
\subsection{DTO - Data Transfer Objects}
Data Transfer Objects\footnote{vgl. \cite{DTO}}  fassen alle Informationen über eine Transaktion (Saldo anzeigen, Geldbetrag abheben, etc...) in eine Klasse zusammen, anstelle mehrere Methodenparameter zum Server zu übertragen. Jedem Use Case wird ein DTO zugeordnet. Sämtliche DTOs erben von einer gemeinsamen Java DTO Oberklasse, welche grundlegende Funktionalitäten aufweist (Zeitbestimmung), welche die vererbten DTOs automatisch implementieren. Dieser Schritt ist maßgeblich für die folgende Verschlüsselung.
\subsection{DTO Verschlüsselung}
Da nun sämtliche Übertragungsparameter in einer Hüllklasse vorliegen, lässt sich diese Klasse serialisieren, um sie für den Transport über das Netzwerk vorzubereiten. Bevor sie nun an den Server/Client geschickt wird, wird sie symmetrisch verschlüsselt. Da die Klasse serialisiert als Bytestrom vorliegt, lässt sich die Verschlüsselung besonders effektiv anwenden. Der symmetrische Schlüssel wird im Vorhinein asymmetrisch zwischen den Partnern ausgetauscht (hybride Verschlüsselung). \par
Auf der Empfängerseite wird der ankommende verschlüsselte Bytestrom entschlüsselt, die Klasse deserialisiert und zum Schluss an den entsprechenden Service weiter delegiert.
\begin{figure}[htb]
 %\centerline{\epsfig{figure=keytool.jpg,width=8.5cm}}
\centerline{\includegraphics[width=120mm]{pics/dto.jpg}}
%  \vspace{2.0cm}
\caption{Serialisierung und Verschlüsselung von einem DTO}
\label{fig:keytool}
\end{figure}
\section{Strategien des Schlüsselaustauschs über mehrere Ebenen}
Die nun vorgestellte Architektur beinhaltet 3 Ebenen der Sicherheit. Auf oberster Ebene wird das VPN abgesichert und verschlüsselt. Auf der mittleren Ebene wird der Kommunikationskanal zwischen Server und Client per SSL verschlüsselt. Schließlich werden auf unterster Ebene die einzelnen Datenpakete zusätzlich verschlüsselt.\par
Jede Ebene erfordert zuerst einmal ihren eigenen öffentlichen und privaten Schlüssel. In der Summe wären dies jeweils drei private und drei öffentliche Schlüssel für Server und Client. Für einen Angreifer wäre diese pessimistische Strategie am schwierigsten zu durchbrechen, da er nach Überwindung der ersten Ebene wieder vor einem neuen Problem steht. Selbst wenn man davon ausgeht, dass er die zweite Ebene entschlüsseln kann steht er nun vor dem Problem, die einzelnen Datenpakete entschlüsseln bzw. manipulieren zu müssen. Diese 3 Hürden verschaffen der Bank zumindest eine große Zeitspanne, in welcher sie das Eindringen von Fremden bereits erkennen kann.\par
Möchte man die Generierung und das Management der vielen Schlüssel vermeiden, bleibt einem noch die Verwendung einer optimistischen Strategie. Man verwendet nur noch die öffentlichen bzw. privaten Schlüssel der obersten Ebene und nutzt diesen gesicherten Kanal, um den symmetrischen Session Key für die zweite Ebene zu übertragen. Da die zweite Ebene nun auch verschlüsselt ist, kann man über diesen Kanal den symmetrischen Session Key für die dritte Ebene aushandeln.