Update German Docs

source/actor/actor.rst

@@ -0,0 +1,17 @@
+Aktoren von FabAccess
+========
+
+Um auch externe oder nicht im Core integirerte Scripte verwenden zu können, ist es möglich diese Skripte als Actor einzubinden.
+Hier bei wird zwischen 3 Stufen eines Actors unterschieden.
+
+Der erste Actor ist ein Modul, welches im FabAccess Core verwendet wird.
+Diese Module werden vom FabAccess Projekt und somit vom FabInfra Team gepflegt.
+Das Module ist in Rust geschrieben und wird mit dem Server kompeliert.
+Auch die Runtime wird von BFFH bestimmt und überwacht.
+
+Die zweite Möglichkeit ist ein Bash Actor. 
+Dieser stellt ein Script da, welches bei einer Statusänderung ausgeführt werden.
+Dabei sollten in diesem Actor keine persistenten Daten verwendet werden.
+
+Um auch externe Daten in das Verhalten des Actors mit einzubeziehen kann ein Process-Actor verwendet werden.
+Der Process Actor erhält hierbei über die Stdin Informationen von BFFH über die Statusänderungen der Maschine.

source/fabfire/fabfire.rst

@@ -0,0 +1,23 @@
+FabFire
+==============
+
+FabFire ist ein Protokoll zur Kommunikation mit NXP MIFARE DESFire Smartcards.
+Mit FabFire kann ein sichere Authentifizierung mit einer Smartcard ausgeführt werden, die auch Föderationsfähig ist.
+
+Bei FabFire wird eine Ende-zu-Ende Verschlüsselte Kommunikation mit der Karte und dem Server aufgebaut. 
+Der Kartenleser benötigt hierbei keine Information zu der Karte.
+
+Das Protokoll wurde entwickelt, um einen Authentifizierung im föderierten System zu ermöglichen.
+Da bei einer Föderation keine Sicherheitsschlüssel ausgetauscht werden sollen, muss eine dirkete Verbindung der Karte zum Server aufgebaut werden.
+Die Trustpoints liegen beim lokalen Space bei der Readern, die mit dem Server verbunden sind, um die Maschine auszuwählen.
+Vom föderietem Server kommen hierbei nur ein Nutzer und die Verifikation der Authentifizierung zurück.
+Somit müssen keine Schlüsseldaten zwischen den Servern ausgetauscht werden.
+Auch sind auf der Karte keine persönlichen Daten des Nutzers gespeichert. 
+Es wird lediglich ein zufällig generierte ID auf der Karte gespeichert, sowie die Informationen über den Heimat Space.
+
+Mehr zum Protokoll findet ihr hier.
+
+Für die Unterstützung des FabFire Protokolls wird keine spezielle Hardware benötigt. Jedoch müssen die Reader softwareseitig das Protokoll zum lokalen Server unterstützten.
+Mehr Information zu den Readern findet ihr hier.
+
+Noch mehr zu der Struktur und Integration in FabAccess findet ihr hier.

source/fabfire/protocol_ger.md

@@ -0,0 +1,20 @@
+# FabFire Protokoll
+Das FabFire Protokoll besteht aus einer direkten Verbindung des Servers mit der SmartCard.
+Die Daten die auf der Smartcard hinterlegt sind stellen hierbeit den Trustpoint da.
+
+Bei der Erstellung der Karte wird eine Applikation mit der ID `0x464142` auf der Karte angelegt.
+Unter dieser Applikaton werden 3 Dateien abgelegt. Alle Dateien werden mit einem `\0` beendet.
+
+In der ersten Datei wir die Versionnummer des verwendeten FabFire-Protokolls abgelegt.
+
+In der zweiten Datei könnne Informationen über den Space, bei dem die Karte ausgestellt wurde abgelegt werden.
+Hierfür kann die Webseite oder eine Lost&Found Mail Adresse hinterlegt werden.
+
+In der dritten Datei werden die Information des Nutzers psedonimisiert abgelegt.
+Die Daten werden als `user@space` abgelegt.
+Der Server kann daraufhin den Server identifizieren und eine Authentifizierung des Nutzers veranlassen.
+
+Beim FabFire Protokoll werden keine direkten Daten auf der Karte gespeichert. Es wird lediglich eine pseudonimisierte ID des Nutzers angelegt, welche direkt mit dem Nutzer gekoppelt wird.
+Die Authentifizierung erfolgt über den Key #1 auf der Applikation.
+
+Der Applikation-Key, als auch der PICC-Key werden für das Protokoll nicht verwendet.

source/fabfire/readers_ger.md

@@ -0,0 +1,21 @@
+# Readers
+Für die Kommunikation zwischen dem Server und der Karte werden APDUs verwendet, die in dem ISO 7816 Standard beschrieben werden.
+
+Der Reader muss daher nach erkennen einer Karte die Kommunikation der DESFire Karte mit den Server vorbereiten.
+Sollte der Reader mit ISO 14446 arbeiten, dann kann das Verfahren zum Aufbau einer APDU Kommunikation verwendet werden.
+
+## Protokoll
+Der Reader baur nach dem Erkennen einer Karte und der Vorbereitung der Kommunikation ein Verbindung mit dem Server oder einem Adapter auf.
+
+Der Reader sollte bei Verlust der Verbindung der Karte den Server informieren. Die Verbindung kann dann erneut gestartet werden, wenn die Karte wieder verfügbar ist.
+
+Nach dem Start der Komunikation erhält der Reader die erste APDU Nachricht, die zur Smartcard weitergeleitet wird. Die entsprechende Response wird dann zum Server weitergeleitet.
+Der Server antwortet auf die Response mit dem nächsten APDU Paket oder beendet die Verbindung zur Karte.
+Der Reader kann dann die Verbindung zur Karte abbauen.
+Um eine Prüfung des Servers zu ermöglichen, ob sich eine Karte noch auf dem Reader befindet, wird die Verbindung vom Server nicht beendet. Und der Server führt darauf hin in regelmäßigen Abständen eine Ping Befehl zur Karte aus.
+
+Die Kommunikation zwischen dem Server und der Karte kann verschlüsst werden, ist aber in jedem Fall CMAC gesichert.
+Somit kann die Integrität der Nachrichten sichergestellt werden.
+
+Der Server kann auch den Reader auffordern, die Verbindung zur Karte neu aufzubauen. So kann der Reader als Deadman Switch verwendet werden.
+

source/fabfire/sasl_ger.md

@@ -0,0 +1,5 @@
+# FabFire in SALS
+In SALS wird eine Kartenkommunikation mit ISO 7816 APDUs als FABFIRE-X Mechanism bezeichnet.
+Der Mechanismus stelle eine Binäre Kommunikation mit der Karte dar.
+Der Server sendet nach einer leeren Nachricht an den Server die APDU Commands an die Karte weiter und schickt die Response an den Server zurück.
+

source/fabfire/structure_ger.md

@@ -0,0 +1,6 @@
+# Struktur von FabFire mit FabAccess
+FabFire stelle nur eine weitere Möglichkeit der Authentifizierung mit der Server da.
+Daher kann FabFire mit jedem Reader verwendet werden und der Reader oder der Adapter kann so sich über die API mit dem Server verbinden und die Maschienen aktivieren.
+
+Der FabFire-Adapter baut hierfür eine Verbindung mit der Server und der MQTT-Verbindung mit der Reader her.
+Der Reader kommuniziert über MQTT, die Befehle müssen über den Adapter in SALS Authentifizierung mit Cap'n Proto übersetzt werden.

source/usage/qr-code_ger.md

@@ -0,0 +1,9 @@
+# QR-Code auf Maschinen
+In Borepin Client werden QR-Codes zur Identitifizierung von Maschinen verwendet.
+
+Somit kann für den Nutzer eine Maschine mit einem Namen, als auf einem QR-Code versehen werden.
+Der QR-Code Inhalt muss dabei eine URN der Maschine entsprechen.
+`urn:fabaccess:resource:{MACHINE_ID}`
+Bei der `{MACHINE_ID}` wird die ID der Maschine verwendet, die in der Konfigurationsdatei für die Maschine gesetzt wurde.
+
+Wenn ihr NFC-Tags auf den Maschienen anbringen wollte, dann schaut hier.