From b0e4af682671da4e17838db7e19788403bf61b85 Mon Sep 17 00:00:00 2001 From: "T. Mulzer" <4284531-tmulzer@users.noreply.gitlab.com> Date: Mon, 21 Sep 2020 16:53:27 +0000 Subject: [PATCH 01/10] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 1197501..4df768d 100644 --- a/README.md +++ b/README.md @@ -45,7 +45,7 @@ Das Szenario, dass die Karte unerlaubt weitergegeben wir, läßt sich alleine ü Zur Zeitwird die Karte einmal gelesen und dann vom Lesegerät abgeschaltet. Eine Option, dass die Anwesenheit der Karte kontinuierlich überprüft wird, könnte bei Bedarf hinzugefügt werden. ### 2. Kommunikation über MQTT -Das Lesegerät kann über die Konfigurationsseite entweder über LAN oder über WLAN in einem Netzwerk eingebunden werden. Die IP-Adresse des Brokers muss, zusammen mit der Geräte-ID ebenfalls manuell über die Konfigurationsseite eingegeben werden. Über standardisierte Adressn (Topics), in der die ID des Lesegerätes enthalten ist, werden Nachrichten (Payload) verschikt. Das Gerät abboniert ebenfalls ein standardisiertes Topic um Nachrichten empfangen zu können. +Das Lesegerät kann über die Konfigurationsseite entweder über LAN oder über WLAN in einem Netzwerk eingebunden werden. Die IP-Adresse des Brokers muss, zusammen mit der Geräte-ID ebenfalls manuell über die Konfigurationsseite eingegeben werden. Über standardisierte Adressen (Topics), in der die ID des Lesegerätes enthalten ist, werden Nachrichten (Payload) verschikt. Das Gerät abboniert ebenfalls ein standardisiertes Topic um Nachrichten empfangen zu können. Die Kommunikation von Nachrichtigen kann entweder als JSON Objekt oder als Klartext erfolgen (über die Konfigurationsseite einstellbar). Nach erfolgreichem Lesen der RFID Karte wird die UID und, wenn eingestellt der alte und neue Zeitstempel an den Broker übermittelt. Das Lesegerät kann eine Reihe von standard-Nachrichten anzeigen (die intern auf das Display passend hinterlegt wurden) oder kann auch Klartext-Nachrichten empfangen und Anzeigen. Hierzu enthält die empfangene MQTT-Nachricht immer ein "identifizierer" der Nachricht und eine Klartextnachricht. Je nachdem ob der Identifizierer im Lesegerät belegt belegt ist, wird die passend formatierte Nachricht angezeigt oder die unformatierte Klartextnachricht. From 1b643e02777013448aec2ba72addc9dc7c7a400e Mon Sep 17 00:00:00 2001 From: "T. Mulzer" <4284531-tmulzer@users.noreply.gitlab.com> Date: Mon, 21 Sep 2020 16:57:04 +0000 Subject: [PATCH 02/10] Update README.md --- README.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index 4df768d..6dbc26c 100644 --- a/README.md +++ b/README.md @@ -35,20 +35,20 @@ Des Konzept lässt sich in mehrere Teilbereiche unterteilen: Das Ziel ist, ein System zur Verfügung zu stellen, welches möglichst wenig anfällig für misbrauch ist, aber dennoch preiswert bleibt. Hierzu gitb es folgende Konzepte: 1. Verwendung von Mifare Classic Karten - Die Karten sind klonbar und bieten daher die geringste Sicherheit 2. Verwendung von Mifare Classic Karten mit Zeitstempel der in einer Datenbank abgelegt wird. Sicherer, da eine geklonte Karte nur einmal verwendet werden kann. Dannach weichen der Zeitstempel auf dem Original und dem Klon von einander ab, und das Vorhandensein zweier Karten kann erkannt werden. Das ganze setzt eine stabile Kommunikation zwischen Lesegerät und Datenbank voraus -3. Verwendung von DESFire Karten. Karten sind teuer und die Empfindlichkeit der Lesegerätes verringert sich -4. Verwendung von Mifare Ultralight C Karten. Die Karten sind günstiger, auch hier leidet die Empfindlichkeit, allerdings muss hier sichergestellt werden, dass es sich um ein Typ C handelt, da die standard Ultralight Karten ebenfalls klonbar sind. Beide karten "identifizieren" sich zunächst jedoch gleich. +3. Verwendung von DESFire Karten. Karten sind teuer und die Empfindlichkeit des Lesegerätes verringert sich +4. Verwendung von Mifare Ultralight C Karten. Die Karten sind günstiger, auch hier leidet die Empfindlichkeit, allerdings muss hier sichergestellt werden, dass es sich um ein Typ C handelt, da die standard Ultralight Karten ebenfalls klonbar sind. Beide Karten "identifizieren" sich zunächst jedoch gleich. Alle 4 Optionen werden vom Lesegerät unterstützt. Die Option kann über die Konfigurationsseite des Lesegerätes eingestellt werden. -Das Szenario, dass die Karte unerlaubt weitergegeben wir, läßt sich alleine über die Wahl der RFID Technologie lösen, daher wird dieses nicht betrachtet. +Das Szenario, dass die Karte unerlaubt weitergegeben wird, läßt sich alleine über die Wahl der RFID Technologie lösen, daher wird dieses nicht betrachtet. -Zur Zeitwird die Karte einmal gelesen und dann vom Lesegerät abgeschaltet. Eine Option, dass die Anwesenheit der Karte kontinuierlich überprüft wird, könnte bei Bedarf hinzugefügt werden. +Zur Zeit wird die Karte einmal gelesen und dann vom Lesegerät abgeschaltet. Eine Option, dass die Anwesenheit der Karte kontinuierlich überprüft wird, könnte bei Bedarf hinzugefügt werden. ### 2. Kommunikation über MQTT -Das Lesegerät kann über die Konfigurationsseite entweder über LAN oder über WLAN in einem Netzwerk eingebunden werden. Die IP-Adresse des Brokers muss, zusammen mit der Geräte-ID ebenfalls manuell über die Konfigurationsseite eingegeben werden. Über standardisierte Adressen (Topics), in der die ID des Lesegerätes enthalten ist, werden Nachrichten (Payload) verschikt. Das Gerät abboniert ebenfalls ein standardisiertes Topic um Nachrichten empfangen zu können. -Die Kommunikation von Nachrichtigen kann entweder als JSON Objekt oder als Klartext erfolgen (über die Konfigurationsseite einstellbar). +Das Lesegerät kann über die Konfigurationsseite entweder über LAN oder über WLAN in einem Netzwerk eingebunden werden. Die IP-Adresse des Brokers muss, zusammen mit der Geräte-ID ebenfalls manuell über die Konfigurationsseite eingegeben werden. Über standardisierte Adressen (Topics), in der die ID des Lesegerätes enthalten ist, werden Nachrichten (Payload) verschickt. Das Gerät abonniert ebenfalls ein standardisiertes Topic um Nachrichten empfangen zu können. +Die Kommunikation von Nachrichten kann entweder als JSON Objekt oder als Klartext erfolgen (über die Konfigurationsseite einstellbar). Nach erfolgreichem Lesen der RFID Karte wird die UID und, wenn eingestellt der alte und neue Zeitstempel an den Broker übermittelt. -Das Lesegerät kann eine Reihe von standard-Nachrichten anzeigen (die intern auf das Display passend hinterlegt wurden) oder kann auch Klartext-Nachrichten empfangen und Anzeigen. Hierzu enthält die empfangene MQTT-Nachricht immer ein "identifizierer" der Nachricht und eine Klartextnachricht. Je nachdem ob der Identifizierer im Lesegerät belegt belegt ist, wird die passend formatierte Nachricht angezeigt oder die unformatierte Klartextnachricht. +Das Lesegerät kann eine Reihe von standard-Nachrichten anzeigen (die intern auf das Display passend hinterlegt wurden) oder kann auch Klartext-Nachrichten empfangen und anzeigen. Hierzu enthält die empfangene MQTT-Nachricht immer ein "identifizierer" der Nachricht und eine Klartextnachricht. Je nachdem ob der Identifizierer im Lesegerät belegt ist, wird die passend formatierte Nachricht angezeigt oder die unformatierte Klartextnachricht. ### 3. Konfiguration des Gerätes -Das Gerät verfügt über einen Eingang zum Anschluss eines Tastest. Wird diese Taste während des Bootvorgangs betätigt, startet das Lesegerät im Web-AP Modus. Nach Anmeldung in das Netzwerk findet man auf der Home-Webseite des Gerätes eine leere Konfigurationsseite. Hier können SSID und Passwort des Werkstatt-Netzwerks, Broker-IP, Geräte-ID, LAN/WLAN und RFID Optionen definiert werden. Die Optionen werden gespeicher und werden beim nächsten Bootvorgang verwendet. \ No newline at end of file +Das Gerät verfügt über einen Eingang zum Anschluss eines Tasters. Wird diese Taste während des Bootvorgangs betätigt, startet das Lesegerät im Web-AP Modus. Nach Anmeldung in das Netzwerk findet man auf der Home-Webseite des Gerätes eine leere Konfigurationsseite. Hier können SSID und Passwort des Werkstatt-Netzwerks, Broker-IP, Geräte-ID, LAN/WLAN und RFID Optionen definiert werden. Die Optionen werden gespeichert und werden beim nächsten Bootvorgang verwendet. \ No newline at end of file From 4b8c8f1fd3ca16ec34773ba86a8b84f0d295b06f Mon Sep 17 00:00:00 2001 From: Joris Date: Tue, 13 Oct 2020 13:55:31 +0000 Subject: [PATCH 03/10] Update README.md --- README.md | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 77 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 6dbc26c..c3b5d06 100644 --- a/README.md +++ b/README.md @@ -34,21 +34,92 @@ Des Konzept lässt sich in mehrere Teilbereiche unterteilen: ### 1. Kommunikation mit RFID-Karten Das Ziel ist, ein System zur Verfügung zu stellen, welches möglichst wenig anfällig für misbrauch ist, aber dennoch preiswert bleibt. Hierzu gitb es folgende Konzepte: 1. Verwendung von Mifare Classic Karten - Die Karten sind klonbar und bieten daher die geringste Sicherheit - 2. Verwendung von Mifare Classic Karten mit Zeitstempel der in einer Datenbank abgelegt wird. Sicherer, da eine geklonte Karte nur einmal verwendet werden kann. Dannach weichen der Zeitstempel auf dem Original und dem Klon von einander ab, und das Vorhandensein zweier Karten kann erkannt werden. Das ganze setzt eine stabile Kommunikation zwischen Lesegerät und Datenbank voraus -3. Verwendung von DESFire Karten. Karten sind teuer und die Empfindlichkeit des Lesegerätes verringert sich -4. Verwendung von Mifare Ultralight C Karten. Die Karten sind günstiger, auch hier leidet die Empfindlichkeit, allerdings muss hier sichergestellt werden, dass es sich um ein Typ C handelt, da die standard Ultralight Karten ebenfalls klonbar sind. Beide Karten "identifizieren" sich zunächst jedoch gleich. + 2. Verwendung von Mifare Classic Karten mit Zeitstempel der in einer Datenbank abgelegt wird. Sicherer, da eine geklonte Karte nur einmal verwendet werden kann. Dannach weichen der Zeitstempel auf dem Original und dem Klon von einander ab, und das Vorhandensein zweier Karten kann erkannt werden. Das ganze setzt eine stabile Kommunikation zwischen Lesegerät und Datenbank voraus. +3. Verwendung von DESFire Karten. Karten sind teuer und die Empfindlichkeit des Lesegerätes verringert sich. Die Kommunikation mit den DESFire Karten erfolgt OTA (Over The Air), d.h. der Server kommuniziert direkt mit der Karte, der Reader schiebt nur die Anfragen und Antworten hin nund her, der Reader versteht diese (teilweise verschlüsselte) Kommunikation nicht. +4. Verwendung von Mifare Ultralight C Karten. Die Karten sind günstiger, auch hier leidet die Empfindlichkeit. Da auch normale Mifare Ultralight Karten geklont werden können, muss die Ultralight "C" Karte mit dem Werkstatt eigenen Schlüssel gesperrt sein. Dieser Schlüssel muss dem Reader vom Server vorher zugeschickt werden (wird also nicht auf der Reader eingespeichert). Alle 4 Optionen werden vom Lesegerät unterstützt. Die Option kann über die Konfigurationsseite des Lesegerätes eingestellt werden. -Das Szenario, dass die Karte unerlaubt weitergegeben wird, läßt sich alleine über die Wahl der RFID Technologie lösen, daher wird dieses nicht betrachtet. +Das Szenario, dass die Karte unerlaubt weitergegeben wird, läßt sich alleine über die Wahl der RFID Technologie lösen, daher bleibt ein gewisses Restrisiko von Missbrauch. Zur Zeit wird die Karte einmal gelesen und dann vom Lesegerät abgeschaltet. Eine Option, dass die Anwesenheit der Karte kontinuierlich überprüft wird, könnte bei Bedarf hinzugefügt werden. ### 2. Kommunikation über MQTT Das Lesegerät kann über die Konfigurationsseite entweder über LAN oder über WLAN in einem Netzwerk eingebunden werden. Die IP-Adresse des Brokers muss, zusammen mit der Geräte-ID ebenfalls manuell über die Konfigurationsseite eingegeben werden. Über standardisierte Adressen (Topics), in der die ID des Lesegerätes enthalten ist, werden Nachrichten (Payload) verschickt. Das Gerät abonniert ebenfalls ein standardisiertes Topic um Nachrichten empfangen zu können. -Die Kommunikation von Nachrichten kann entweder als JSON Objekt oder als Klartext erfolgen (über die Konfigurationsseite einstellbar). +Die Kommunikation von Nachrichten erfolgt als JSON Objekt. Nur die UID kann auch als Klartext übermittelt werden (über die Konfigurationsseite einstellbar). Nach erfolgreichem Lesen der RFID Karte wird die UID und, wenn eingestellt der alte und neue Zeitstempel an den Broker übermittelt. Das Lesegerät kann eine Reihe von standard-Nachrichten anzeigen (die intern auf das Display passend hinterlegt wurden) oder kann auch Klartext-Nachrichten empfangen und anzeigen. Hierzu enthält die empfangene MQTT-Nachricht immer ein "identifizierer" der Nachricht und eine Klartextnachricht. Je nachdem ob der Identifizierer im Lesegerät belegt ist, wird die passend formatierte Nachricht angezeigt oder die unformatierte Klartextnachricht. +Jede Nachricht hat ebenfalls einen Zusatztext, mit dem zusätzliche Varibale Informationen wie Dauer, Uhrzeit, User etc. zu einer Nachricht gezeigt werden können. + +JSON object = {"Cmd": "message", "MssgID": 4 , "ClrTxt":"Hello World" , "AddnTxt":"3:00"} ### 3. Konfiguration des Gerätes -Das Gerät verfügt über einen Eingang zum Anschluss eines Tasters. Wird diese Taste während des Bootvorgangs betätigt, startet das Lesegerät im Web-AP Modus. Nach Anmeldung in das Netzwerk findet man auf der Home-Webseite des Gerätes eine leere Konfigurationsseite. Hier können SSID und Passwort des Werkstatt-Netzwerks, Broker-IP, Geräte-ID, LAN/WLAN und RFID Optionen definiert werden. Die Optionen werden gespeichert und werden beim nächsten Bootvorgang verwendet. \ No newline at end of file +Das Gerät verfügt über einen Eingang zum Anschluss eines Tasters. Wird diese Taste während des Bootvorgangs betätigt, startet das Lesegerät im Web-AP Modus. Nach Anmeldung in das Netzwerk (mit den im Quellcode festgelegten Daten) findet man auf der Home-Webseite des Gerätes (192.168.4.1/) eine leere Konfigurationsseite. Hier können SSID und Passwort des Werkstatt-Netzwerks, Broker-IP, Geräte-ID, LAN/WLAN und RFID Optionen definiert werden. Die Optionen werden gespeichert und werden beim nächsten Bootvorgang verwendet. + +### 4. MQTT-Befehle und Parameter +Nachrichten werden immer als JSON paket übermittelt. Dabei ist der Befehl "Cmd" immer das erste Element. Folgende Befehle sind für "Cmd" definiert: +- "message" - Nachricht auf dem Display zeigen +- "sendPICC" - Daten an DESFire Karte im APDU format schicken +- "haltPICC" - DESFire Karte wird abgemeldet +- "Key" - Zugriffschlüssel für den Zugriff auf Mifare C Karten +- "ConfirmUser" - Reader fordert den Nutzer (durch Fiepen) auf, seine Anwesenheit bei der Maschine zu besätigen (TODO) + + +#### "message" +Nachricht auf dem Display. +Beispiel: {"Cmd": "message", "MssgID": 4 , "ClrTxt":"Hello World" , "AddnTxt":"3:00"} + +| Befehl | Parameter | Format | Bedeutung | +| ------- | --------- | ------- | -------------------------------- | +| "Cmd" | "message" | String | Nachricht auf dem Display anzeigen | +| "MssgID" | zahl | int | vordefinierte Nachricht anzeigen. Die Nachricht wird im QUellcode definiert. Hier wird eine, zum verendeten Display sinnvollen Zeilenumbruch definiert. | +| "ClrTxt"| Freitext | String | Nachricht in Klartext. Wird ignoriert wenn die Nachricht im Reader vordefiniert ist. Ansonsten wird die Nachricht "irgendwie" auf dem Display angezeigt. | +|"AddnTxt"| Freitext | String | Zusatztext, der auf dem Display angezeigt werden soll. Hier können zusätzlich zu fest definierte Nachrichten Ergänzungen wie Uhrzeit, Dauer, Nutzungskosten oder User angezeigt werden. ACHTUNG: das € Zeichen wird auf einige Displays nicht dargestellt. | + +Vordefinierte Nachrichten sind: +|Nr.| Anzeigetext | Zeilenumbruch | englischen Text | +| - | ----------- | ------------- | --------------- | +| 0 |"verfügbar", | 0 | equipment available | +| 1 |"reserviert", | 0 | equipment reserved | +| 2 |"reserviert ab", | 13 | reserved starting from | +| 3 |"in Benutzung", | 0 | equipment in use | +| 4 |"freigegeben", | 0 | access granted | +| 5 |"Anmeld. fehlgeschlagen", | 8 | login error | +| 6 |"Nutzungsgebühr ", | 15 | usage fee | +| 7 |"Nutzung nicht erlaubt", | 13 | operation not allowed | +| 8 |"Nutzung auf eigenem Risiko", | 11 | operation at own risk | +| 9 |"gesperrt durch", | 14 | equipment locked by | +| 10 |"freizugeben durch", | 11 | to be released by | +| 11 |"außerhalb der Nutzungzeit", | 14 | outside ooperating hours | +| 12 |"Nutzungsdauer", | 13 | duration of use | +| 13 |"abgemeldet", | 0 | logged out | +| 14 |"abschalten in", | 13 | equipment will lock down | +| 15 |"Karte gesperrt", | 0 | card locked | +| 16 |"Karte unbekannt", | 0 | card unknown | +| 17 |"Berechtigung endet", | 12 | training to expire | +| 18 |"Ruhemodus"}; | 0 | sleep mode | + + +#### "sendPICC" +Nachricht auf dem Display. +Beispiel: {"Cmd": "sendPICC", "data": "9060000000"} - getVersion Befehl 0x60 + +| Befehl | Parameter | Format | Bedeutung | +| ------- | ---------- | ------- | -------------------------------- | +| "Cmd" | "sendPICC" | String | Daten als APDU kommando an DESFire Karte schicken | +| "data" | APDU Paket | String | Komplettes APDU Paket als lesbarer Hex-Zeichen. für A bis F können Groß- oder Kleinbuchstaben verwendet werden. | + +Der Reader antwortet mit einem APDU-Paket z.B. {"Cmd":"readPICC","data":"04010112001A0591AF"}. Dabei sind die letzten zwei Bytes die Statusbytes (0x91AF = es gibt noch mehr Daten -> DESFire Statusmeldungen) + +#### "haltPICC" +Die kommunikation mit der DESFire Karte wird beendet. Dieser Befehl ist nur bei DESFire Karten notwendig, da Mifare Classic und Mifare Ultralight C Karten automatisch abgemeldet werden. +Beispiel: {"Cmd": "haltPICC"} + +| Befehl | Parameter | Format | Bedeutung | +| ------- | ---------- | ------- | -------------------------------- | +| "Cmd" | "haltPICC" | String | Kommunkation zwischen Reader und DESFire Karte wird beendet | + + + * communicate with reader - JSON object = {"Cmd": "haltPICC"} + * recieve auth Key - JSON object = {"Cmd": "Key", "data": 0123456789ABCDEF} // data in ASCII + * Confirm User attendence - JSON object = {"Cmd": "ConfirmUser"} \ No newline at end of file From 2185243cdedb0b2882bc1a3520f35e2532dab0ed Mon Sep 17 00:00:00 2001 From: Joris Date: Tue, 13 Oct 2020 13:59:59 +0000 Subject: [PATCH 04/10] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index c3b5d06..1572a14 100644 --- a/README.md +++ b/README.md @@ -77,7 +77,7 @@ Beispiel: {"Cmd": "message", "MssgID": 4 , "ClrTxt":"Hello World" , "AddnTxt":"3 |"AddnTxt"| Freitext | String | Zusatztext, der auf dem Display angezeigt werden soll. Hier können zusätzlich zu fest definierte Nachrichten Ergänzungen wie Uhrzeit, Dauer, Nutzungskosten oder User angezeigt werden. ACHTUNG: das € Zeichen wird auf einige Displays nicht dargestellt. | Vordefinierte Nachrichten sind: -|Nr.| Anzeigetext | Zeilenumbruch | englischen Text | +| Nr.| Anzeigetext | Zeilenumbruch | englischen Text | | - | ----------- | ------------- | --------------- | | 0 |"verfügbar", | 0 | equipment available | | 1 |"reserviert", | 0 | equipment reserved | From aa6230129301304f09bbdb57b44bfcfbb905607f Mon Sep 17 00:00:00 2001 From: Joris Date: Tue, 13 Oct 2020 14:01:26 +0000 Subject: [PATCH 05/10] Update README.md --- README.md | 43 ++++++++++++++++++++++--------------------- 1 file changed, 22 insertions(+), 21 deletions(-) diff --git a/README.md b/README.md index 1572a14..ccd2673 100644 --- a/README.md +++ b/README.md @@ -77,27 +77,28 @@ Beispiel: {"Cmd": "message", "MssgID": 4 , "ClrTxt":"Hello World" , "AddnTxt":"3 |"AddnTxt"| Freitext | String | Zusatztext, der auf dem Display angezeigt werden soll. Hier können zusätzlich zu fest definierte Nachrichten Ergänzungen wie Uhrzeit, Dauer, Nutzungskosten oder User angezeigt werden. ACHTUNG: das € Zeichen wird auf einige Displays nicht dargestellt. | Vordefinierte Nachrichten sind: -| Nr.| Anzeigetext | Zeilenumbruch | englischen Text | -| - | ----------- | ------------- | --------------- | -| 0 |"verfügbar", | 0 | equipment available | -| 1 |"reserviert", | 0 | equipment reserved | -| 2 |"reserviert ab", | 13 | reserved starting from | -| 3 |"in Benutzung", | 0 | equipment in use | -| 4 |"freigegeben", | 0 | access granted | -| 5 |"Anmeld. fehlgeschlagen", | 8 | login error | -| 6 |"Nutzungsgebühr ", | 15 | usage fee | -| 7 |"Nutzung nicht erlaubt", | 13 | operation not allowed | -| 8 |"Nutzung auf eigenem Risiko", | 11 | operation at own risk | -| 9 |"gesperrt durch", | 14 | equipment locked by | -| 10 |"freizugeben durch", | 11 | to be released by | -| 11 |"außerhalb der Nutzungzeit", | 14 | outside ooperating hours | -| 12 |"Nutzungsdauer", | 13 | duration of use | -| 13 |"abgemeldet", | 0 | logged out | -| 14 |"abschalten in", | 13 | equipment will lock down | -| 15 |"Karte gesperrt", | 0 | card locked | -| 16 |"Karte unbekannt", | 0 | card unknown | -| 17 |"Berechtigung endet", | 12 | training to expire | -| 18 |"Ruhemodus"}; | 0 | sleep mode | + +| Nr.| Anzeigetext | Zeilenumbruch bei | englischen Text | +| -- | ----------- | ------------- | --------------- | +| 0 | "verfügbar", | 0 | equipment available | +| 1 | "reserviert", | 0 | equipment reserved | +| 2 | "reserviert ab", | 13 | reserved starting from | +| 3 | "in Benutzung", | 0 | equipment in use | +| 4 | "freigegeben", | 0 | access granted | +| 5 | "Anmeld. fehlgeschlagen", | 8 | login error | +| 6 | "Nutzungsgebühr ", | 15 | usage fee | +| 7 | "Nutzung nicht erlaubt", | 13 | operation not allowed | +| 8 | "Nutzung auf eigenem Risiko", | 11 | operation at own risk | +| 9 | "gesperrt durch", | 14 | equipment locked by | +| 10 | "freizugeben durch", | 11 | to be released by | +| 11 | "außerhalb der Nutzungzeit", | 14 | outside ooperating hours | +| 12 | "Nutzungsdauer", | 13 | duration of use | +| 13 | "abgemeldet", | 0 | logged out | +| 14 | "abschalten in", | 13 | equipment will lock down | +| 15 | "Karte gesperrt", | 0 | card locked | +| 16 | "Karte unbekannt", | 0 | card unknown | +| 17 | "Berechtigung endet", | 12 | training to expire | +| 18 | "Ruhemodus"}; | 0 | sleep mode | #### "sendPICC" From b92fc50a9967c4731d25c595ddfb4142e46c34b7 Mon Sep 17 00:00:00 2001 From: Joris Date: Tue, 13 Oct 2020 14:04:40 +0000 Subject: [PATCH 06/10] Update README.md --- README.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index ccd2673..63c8b63 100644 --- a/README.md +++ b/README.md @@ -110,7 +110,9 @@ Beispiel: {"Cmd": "sendPICC", "data": "9060000000"} - getVersion Befehl 0x60 | "Cmd" | "sendPICC" | String | Daten als APDU kommando an DESFire Karte schicken | | "data" | APDU Paket | String | Komplettes APDU Paket als lesbarer Hex-Zeichen. für A bis F können Groß- oder Kleinbuchstaben verwendet werden. | -Der Reader antwortet mit einem APDU-Paket z.B. {"Cmd":"readPICC","data":"04010112001A0591AF"}. Dabei sind die letzten zwei Bytes die Statusbytes (0x91AF = es gibt noch mehr Daten -> DESFire Statusmeldungen) +Der Reader antwortet mit einem APDU-Paket z.B. +{"Cmd":"readPICC","data":"04010112001A0591AF"}. +Dabei sind die letzten zwei Bytes die Statusbytes (0x91AF = es gibt noch mehr Daten -> DESFire Statusmeldungen) #### "haltPICC" Die kommunikation mit der DESFire Karte wird beendet. Dieser Befehl ist nur bei DESFire Karten notwendig, da Mifare Classic und Mifare Ultralight C Karten automatisch abgemeldet werden. From e7021e293532a6e594051e26c66e3cb0fc60929f Mon Sep 17 00:00:00 2001 From: Joris Date: Tue, 13 Oct 2020 16:36:28 +0000 Subject: [PATCH 07/10] Update README.md --- README.md | 66 ++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 43 insertions(+), 23 deletions(-) diff --git a/README.md b/README.md index 63c8b63..0e60e27 100644 --- a/README.md +++ b/README.md @@ -80,29 +80,30 @@ Vordefinierte Nachrichten sind: | Nr.| Anzeigetext | Zeilenumbruch bei | englischen Text | | -- | ----------- | ------------- | --------------- | -| 0 | "verfügbar", | 0 | equipment available | -| 1 | "reserviert", | 0 | equipment reserved | -| 2 | "reserviert ab", | 13 | reserved starting from | -| 3 | "in Benutzung", | 0 | equipment in use | -| 4 | "freigegeben", | 0 | access granted | -| 5 | "Anmeld. fehlgeschlagen", | 8 | login error | -| 6 | "Nutzungsgebühr ", | 15 | usage fee | -| 7 | "Nutzung nicht erlaubt", | 13 | operation not allowed | -| 8 | "Nutzung auf eigenem Risiko", | 11 | operation at own risk | -| 9 | "gesperrt durch", | 14 | equipment locked by | -| 10 | "freizugeben durch", | 11 | to be released by | -| 11 | "außerhalb der Nutzungzeit", | 14 | outside ooperating hours | -| 12 | "Nutzungsdauer", | 13 | duration of use | -| 13 | "abgemeldet", | 0 | logged out | -| 14 | "abschalten in", | 13 | equipment will lock down | -| 15 | "Karte gesperrt", | 0 | card locked | -| 16 | "Karte unbekannt", | 0 | card unknown | -| 17 | "Berechtigung endet", | 12 | training to expire | -| 18 | "Ruhemodus"}; | 0 | sleep mode | +| 0 | "verfügbar" | 0 | equipment available | +| 1 | "reserviert" | 0 | equipment reserved | +| 2 | "reserviert ab" | 13 | reserved starting from | +| 3 | "in Benutzung" | 0 | equipment in use | +| 4 | "freigegeben" | 0 | access granted | +| 5 | "Anmeld. fehlgeschlagen" | 8 | login error | +| 6 | "Nutzungsgebühr " | 15 | usage fee | +| 7 | "Nutzung nicht erlaubt" | 13 | operation not allowed | +| 8 | "Nutzung auf eigenem Risiko" | 11 | operation at own risk | +| 9 | "gesperrt durch" | 14 | equipment locked by | +| 10 | "freizugeben durch" | 11 | to be released by | +| 11 | "außerhalb der Nutzungzeit" | 14 | outside ooperating hours | +| 12 | "Nutzungsdauer" | 13 | duration of use | +| 13 | "abgemeldet" | 0 | logged out | +| 14 | "abschalten in" | 13 | equipment will lock down | +| 15 | "Karte gesperrt" | 0 | card locked | +| 16 | "Karte unbekannt" | 0 | card unknown | +| 17 | "Berechtigung endet" | 12 | training to expire | +| 18 | "Ruhemodus" | 0 | sleep mode | +| 19 | "Aufsicht bestätigen" | 8 | confirm presence | #### "sendPICC" -Nachricht auf dem Display. +APDU Paket an DESFire Karte schicken. Beispiel: {"Cmd": "sendPICC", "data": "9060000000"} - getVersion Befehl 0x60 | Befehl | Parameter | Format | Bedeutung | @@ -122,7 +123,26 @@ Beispiel: {"Cmd": "haltPICC"} | ------- | ---------- | ------- | -------------------------------- | | "Cmd" | "haltPICC" | String | Kommunkation zwischen Reader und DESFire Karte wird beendet | +#### "Key" +Da der der Schlüssel der WErkstatt spezifisch für die Kodierung von Mifare Ultralight C Karten festgelegt wurde möglichst nicht in der Quellcode auftauchen sollte, muss dieser über den Server bereitgestellt werden. Dieser Befehl übermittelt den Schlüssel. Über einen im Server festgelegten Prozess muss sichergestellt werden, dass dieser Schlüssel nur dann verschickt wird, wenn auch sicher ein authorisiertes Lesegerät vorhanden ist. Dieser Befehl ist nur für Mifare Ultralight C Karten. - * communicate with reader - JSON object = {"Cmd": "haltPICC"} - * recieve auth Key - JSON object = {"Cmd": "Key", "data": 0123456789ABCDEF} // data in ASCII - * Confirm User attendence - JSON object = {"Cmd": "ConfirmUser"} \ No newline at end of file +Beispiel: {"Cmd": "Key", "data": 49454D4B41455242214E4143554F5946} (Mifare Ultralight C standard Schlüssel) + +| Befehl | Parameter | Format | Bedeutung | +| ------- | ---------- | ------- | -------------------------------- | +| "Cmd" | "Key" | String | Schlüssel wird übermittelt | +| "data" | 32 Hex Zeichen | String | Zugriffsschlüssel für die Mifare Ultralight c Karte. Im Reader werden die ersten 8 Bytes (erst 16 Zeichen) hinten angehängt um einen 24 Byte schlüssel zu erzeugen| + + +#### "ConfirmUser" (ToDo) +Fordert den Nutzer der Maschine durch lautes Fiepen auf die Anwesenheitstaste betätigen. +Beispiel: {"Cmd": "ConfirmUser"} + +| Befehl | Parameter | Format | Bedeutung | +| ------- | ---------- | ------- | -------------------------------- | +| "Cmd" | "ConfirmUser" | String | Reader fängt an zu fiepen | + +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"}. \ No newline at end of file From 1b8bd4d55e9bd7a5ff83d827014b305274740e75 Mon Sep 17 00:00:00 2001 From: Joris Date: Wed, 14 Oct 2020 09:35:55 +0000 Subject: [PATCH 08/10] Update README.md --- README.md | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 0e60e27..c7f9cfe 100644 --- a/README.md +++ b/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"}. \ No newline at end of file +{"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. \ No newline at end of file From a1c2350383862d2b105ed3420fb292be66dbc3f7 Mon Sep 17 00:00:00 2001 From: Joris Date: Wed, 14 Oct 2020 09:36:42 +0000 Subject: [PATCH 09/10] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index c7f9cfe..a700a46 100644 --- a/README.md +++ b/README.md @@ -160,7 +160,7 @@ Es existieren eine vielzahl von "Magic Cards" die über verschiedene Lesegeräte 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 +#### Verschlüsselung 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. From a8c06fbb59fb8e7d3e544abf2e23fade16fec9b8 Mon Sep 17 00:00:00 2001 From: Joris Date: Wed, 14 Oct 2020 09:46:25 +0000 Subject: [PATCH 10/10] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index a700a46..34139ba 100644 --- a/README.md +++ b/README.md @@ -40,7 +40,7 @@ Das Ziel ist, ein System zur Verfügung zu stellen, welches möglichst wenig anf Alle 4 Optionen werden vom Lesegerät unterstützt. Die Option kann über die Konfigurationsseite des Lesegerätes eingestellt werden. -Das Szenario, dass die Karte unerlaubt weitergegeben wird, läßt sich alleine über die Wahl der RFID Technologie lösen, daher bleibt ein gewisses Restrisiko von Missbrauch. +Das Szenario, dass die Karte unerlaubt weitergegeben wird, läßt sich nicht alleine über die Wahl der RFID Technologie lösen, daher bleibt ein gewisses Restrisiko von Missbrauch. Zur Zeit wird die Karte einmal gelesen und dann vom Lesegerät abgeschaltet. Eine Option, dass die Anwesenheit der Karte kontinuierlich überprüft wird, könnte bei Bedarf hinzugefügt werden.