Update README.md

README.md

@@ -145,4 +145,30 @@ Beispiel: {"Cmd": "ConfirmUser"}
 Die Angezeigte Nachricht, dass der Nutzer seine Aufsicht bestätigen soll (Nachricht 19), muss separat an den Reader verschickt werden.
 
 Der Reader antwortet mit einem APDU-Paket (ToDo) 
-{"Cmd":"UserConfirmed"}.
+{"Cmd":"UserConfirmed"}.
+
+## Sicherheit des Systems
+Das System kann den Zutritt verwalten, Maschinen freischalten die eine Sicherheitseinweisung/Schulung erfordern oder es kann dazu genutzt werden Nutzungszeiten oder Bezahlvorgänge indirekt zu erfassen. 
+Zur Vermeidung von Diebstahl, gefährliche Nutzung von Maschinen oder das Abrechnen von Leistung auf Kosten anderer sind von Hardwareseite zwei Szenarien zu betrachten:
+- Es wird eine RFID-Karte dupliziert
+- Es wird ein Lesegerät manipuliert 	
+
+### 1. RFID Karten
+#### UID
+Die einfachste Art und Weise der Identifizierung über RFID ist die Verwendung der UID (Unique Idenification - Seriennummer) der Karte. Gleichzeitig ist das auch die unsicherste Variante! 
+Es existieren eine vielzahl von "Magic Cards" die über verschiedene Lesegeräte neu konfiguriert werden können. Auf diese Weise kann die UID neu beschrieben werden. Da die UID beim ersten Lesevorgang der RFID-Karte bereits bekannt gegeben wird (auch wenn die Karte verschlüsselt ist), ist es ein leichtes die UID einer bestehende Karte zu ermitteln und diese auf einer "Magic Card" zu übertragen.
+Als erste Schritt zur Erhöhung der Sicherheit kann man den Typ der gelesene Karte identifizieren (über den sogenannten SAK Wert). Auch hier gibt es mittlerweile "Magic Cards" bei denen sogar der SAK-wert geändert werden kann, und die Karte sich somit als einen beliebigen Typ identifiziert.
+#### Karten Typ abfragen
+Als zweiter Schritt sollte man daher Typ-spezifische Anfragen starten um sicher zu gehen, dass es sich auch tatsächlich um den vorgetäuschten Typ handelt. Identtifiziert sich die Karte als DESFire (SAK=0x20), kann man ein DESFire-spezifischen Befehl schicken. Nur so, läßt sich sicherstellen, dass es sich auch tatsächlich um eine Karte diesen Typs handelt. Diese Vorgehensweise reicht nur für den Typ Mifare Plus aus, für alle andere jedoch nicht, da es mittlerweile zu jede andere "sichere" Karte auch "Magic Cards" gibt.
+#### Verschlüsslung
+Als dritter Schritt bleibt somit nur die Freigabe übver eines geheimen Schlüssels oder die verschlüsselte Kommunikation mit der Karte übrig. Hier eigenen sich nur Mifare Classic, Mifare Ultralight C, Mifare Desfire und Mifare Plus, andere (Standard-) Karten sind unverschlüsselt und können daher kopiert werden. Bei der Verschlüsselung gilt es zwischen den System Crypto1 (Mifare Classic) und DES/AES (Ultralight C, DESFire, Mifare Plus) zu unterscheiden. Ersteres ist gehackt und die Daten können mit etwas Aufand dupliziert werden (inkl. Schlüssel). DES / AES ist in zusammenhang mit RFID noch nicht gehackt, kann also als sicher angesehen werden.
+#### Zeitstempel
+Eine alternative Methode ist die Verwendung eines Zeitstempels auf der Karte, der mit jedem Lesevorgang aktualisiert wurd und mit einem gespeicherten Zeitstempel abgeglichen wird. Dieser Zeitstempel kann sogar unverschlüsselt gespeichert werden, da nach dem Klonen einer Karte, nur einer der beiden Klone weiterverwendet werden kann. Die andere Karte ist nach der ersten Aktualisierung des Zeitstempels ungültig.
+
+### 2. ESP8266 / ESP32
+Im Gegensatz zu übliche Microcontroller werden beim ESP8266 Daten auf einem extenen Flash gespeichert. Somit werden auch die Daten auf den externen Bauteil gespeichert die für die Kommunikation, und somit für die Sicherheit des Systems relevant sind. Der ESP8266 bietet keinen Verschlüsselung dieser Daten, sie können daher aus dem Flash ausgelesen werden. Hierzu muss das Lesegerät zerlegt werden und der Flash separat ausgelesen werden. Da Netzwerkkennung im Lesegerät gespeichert sind, sollte der Diebstahl / Ausfall eines Lesegerätes somit kontinuierlich geprüft werden, und die Aktivierung des Lesegerätes über das System erfolgen. 
+Der ESP32 verfügt im Gegensätz zum ESP8266 über eine Verschlüsselung der Daten auf dem Flash, allerdings gibt es auch hier bereits eine Methode diese Verschlüsselung zu umgehen. 
+Der einzige Weg hier ein "Angriff" auf das System zu vermeiden ist, dass ein Lesegerät sich beim Server authentifizieren. Diese Authentifizierung darf nicht im Flash gespeichert sein (da dann ja wieder auslesbar). Daher ist angedacht, die Authentifizierung über eine separate Master-RFID Karte erfolgen zu lassen. Nur wenn diese Karte am Lesegerät gehalten wird wird das Gerät bei Server authentifiziert. Sollte das Mifare Ultralight C system verwendet werden, sollte auch erst dann der Schlüssel übertragen werden. 
+
+### 3. TLS-verschlüsselung (ToDo)
+Damit Daten in der Kommunikation nicht abgehört werden können ist geplant, dass die Kommunikation mit dem Server TLS-verschlüsselt wird. Diese TLS-verschlüsselung sollte idealerweise ebenfalls nicht im Flash gespeichert sein. Hier gibt es das Bestreben, die relevante Daten für die Verschlüsselung (Keys) ebenfalls per RFID-Karte auf die Lesegeräte zu übertragen. Dieser Vorgang kann dann gleichzeitig auch als Authentification des Lesegerätes dienen.