1 files changed, 84 insertions, 0 deletions
diff --git a/doc/devel/0310-service-discovery.tex b/doc/devel/0310-service-discovery.tex
new file mode 100644
index 0000000..307234f
--- /dev/null
+++ b/doc/devel/0310-service-discovery.tex
@@ -0,0 +1,84 @@
+Die Zuordnung von Clients zur Konsole erfolgt halb automatisch über ein
+Service-Discovery-Modul. Jede Konsole sendet im Intervall von 7 Sekunden
+einen Broadcast ins lokale Subnetz, um ihre Verfügbarkeit bekannt zu geben.
+Die Clients können dadurch eine Liste von verfügbaren Servern anzeigen,
+aus der der Benutzer nur noch den gewünschten auswählen muss.
+Das Intervall sowie die verwendeten UDP-Ports für das Service-Discovery
+können vor dem Kompilieren in der \textit{setup.h} festgelegt werden
+\begin{verbatim}
+#define SB_INTERVAL 7 // Broadcast interval in seconds
+#define SD_PORT_CONSOLE 3491 // Not really used, Qt just wants a bind
+#define SD_PORT_CLIENT 3492 // This is where we expect announcements
+\end{verbatim}
+Die zuständigen Klassen sind \textit{PVSServiceBroadcast} (Serverseitig) und
+\textit{PVSServiceDiscovery} (Clientseitig).\\
+Auf Seite des Clients erfolgt außerdem eine Kommunikation mit der GUI
+über DBus, um verfügbare Sitzungen anzeigen zu lassen, und damit
+die GUI den Daemon veranlassen kann, zu einer bestimmten Sitzung
+zu verbinden.
+Die Methode \textit{connectToSession} in \textit{PVSServiceDiscovery}
+ist dafür zuständig, zu einem gegebenem Sitzungsnamen die nötigen
+Daten zu ermitteln und eine Verbindung zu initialisieren.
+
+\subsubsection{Absicherung und Verifikation der Identität}
+
+Um das Fälschen bzw. Manipulieren von diesen Broadcasts zu verhindern,
+sodass es nicht möglich ist, Man-in-the-Middle Angriffe oder ähnliches
+durchzuführen, soll gewährleistet werden, dass eine angezeigte Sitzung
+auch die ist, für die man sie hält.
+
+Dafür wird auf das SSL-Protokoll zurückgegriffen. Zum einen bietet SSL
+Verschlüsselung für Verbindungen an, und das Qt-Framework hat hierfür
+auch schon einige Klassen parat. Zum anderen ist mit SSL durch seine
+Zertifikate auch Identitätsverifikation möglich. Dazu kann das Zertifikat
+des Servers anhand des Fingerprints auf Echtheit überprüft werden.
+Beim Start der Konsole wird also, falls noch nicht vorhanden, ein neues
+Serverzertifikat inklusive Schlüsselpaar erstellt, mit welchem Verbindungen
+mit Clients fortan verschlüsselt werden. Außerdem wird der Fingerprint des
+Zertifikats in den Service-Broadcasts übertragen, sodass die Clients
+bereits vor der Verbindung den zu erwartenden Fingerprint kennen.
+Somit kann beim Aufbau der Verbindung zur Konsole der Fingerprint
+verglichen und eine eventuelle Manipulation erkannt werden.
+
+Für die Eindeutigkeit ist nur noch eine feste Zuordnung von Sitzungsnamen,
+welcher dem Benutzer angezeigt wird, zum Fingerprint der zugehörigen
+Konsole notwendig. Dies wird mit Hilfe eines einfachen Algorithmus erreicht,
+der aus dem Fingerprint einen lesbaren String erzeugt. Wichtig ist, dass
+Konsole und Client hier denselben Algorithmus verwenden, damit der
+Dozent an der Konsole den Studenten den korrekten Sitzungsnamen mitteilen
+kann. Wird der Algorithmus auf Seite der Konsole verändert, müssen auch
+alle Clients aktualisiert werden. Er befindet sich in der \textit{serviceDiscoveryUtil.h}
+und heißt \textit{sha1ToReadable}.
+
+Empfängt der Client einen Broadcast über einen neuen Server, baut dieser
+zunächst zur Überprüfung eine Verbindung zu diesem Server auf und sofort wieder
+ab, um den Fingerprint überprüfen zu können. Nur wenn dieser mit dem
+angekündigten Fingerprint aus dem Broadcast übereinstimmt, wird die Sitzung
+dem Benutzer zur Auswahl angezeigt.
+
+Die Überprüfung geschieht nicht sofort beim Empfang eines Service-Announcements
+sondern verzögert in einem Timer, und dabei auch jeweils nur ein Server
+in jedem Timer-Aufruf. Dies soll Missbrauch durch gefälschte Broadcastpakete
+verhindern oder zumindest stark verlangsamen. Entsprechende Mechanismen gegen
+Missbrauch finden sich in \textit{PVSServiceDiscovery::handleDiscovery} sowie
+\textit{PVSServiceDiscovery::timerEvent}.
+
+\subsubsection{Generierung von Sitzungsnamen}
+
+Hier ist prinzipiell viel Spielraum für Kreativität vorhanden, beachtet werden
+sollte lediglich, dass die Zahl der möglichen Namen, die durch den Algorithmus
+erzeugt werden können, hoch genug ist, um nicht in kurzer Zeit durch einen
+Brute-Force-Angriff einen Fingerprint mit dem selben Sitzungsnamen erzeugen zu
+können. Außerdem sollte die Verteilung der zufälligen Namen über den Raum der
+möglichen Namen etwa gleichmäßig sein.
+
+Der momentan verwendete Algorithmus generiert fünfsilbige Wörter, wobei jede
+Silbe aus einem Konsonanten und einem Vokal besteht. Die Konsonanten werden
+aus einer Liste von 13 Stück ausgewählt, wobei identisch oder zu ähnlich klingende
+Konsonanten herausgefiltert wurden, um bei der mündlichen Übertragung keine
+Ambiguitäten zu erzeugen. mit einer Wahrscheinlichkeit von 25\% wird einer Silbe
+ein \textbf{n} angehängt. Damit sind $130^5 = 37.129.300.000$ (37 Mrd.)
+unterschiedliche Sitzungsnamen möglich, was zwar deutlich weniger sind, als bei
+einem 160Bit langen SHA1-Hash, allerdings ist dies bezogen auf das Einsatzgebiet
+mehr als ausreichend. Alternativ bleibt natürlich nach wie vor das verwenden
+alternativer Algorithmen die einen größeren Raum an möglichen Namen haben.
+\ No newline at end of file