[OpenKNX-Ready] Zutrittskontrolle mit Fingerprint / Fingerabdruck

[mumpf]

werde ich die Klingelfunktion wieder deaktivieren.

Ich hatte schon zu Anfang zu Andreas gesagt, diese Funktion wollen die Leute alle haben, aber nur solange, bis sie sie ausprobieren können, dann werden sie sie abschalten. Aber implementieren musst Du sie, sonst gibt es dauernd "gemecker".

Meine Gründe:

• Klingeln bei "nicht erkannt" bedeutet auch klingeln bei "Fehlerkennung" -> das will man normalerweise nicht
• "Nicht erkannt" kann erst kommen, wenn alle Finger durchsucht sind, also "laaange" (ca. 0.5s) nach dem ersten Touch -> das wirkt träge

Hinzu kommen noch die Bedenken von henfri, die ich durchaus teile.

Ich überlege noch, ob ich es nach 3 oder 4 "nicht erkannt" klingeln lasse. Das nur, weil - trotz vorhandenem Klingelknopf - manche der Meinung sind, es über den FP versuchen zu müssen. Und wenn jemand so geduldig ist, es 4 mal zu versuchen, dann soll er auch belohnt werden .

Gruß, Waldemar

[mumpf]

Wenn jemand ohne Schuhe kommt, reagiert der FP nicht.

Das ist kein Scherz, oder?

Was muss den genau erfüllt sein? Barfuß, Socken? Hast Du eine Metallplatte/Metallgitter/Metalltreppe vor der Tür? Steht man dann drauf? Ist noch eine Matte zwischen Fußboden und den Füßen?

Ernsthaft, ich würde das gerne verstehen... ich habe schon zig mal den Fingerprint Barfuß, auf Socken usw. getestet. Das war noch nie ein Problem. Du musst irgendwas besonderes vor der Tür haben.

Gruß, Waldemar

[mumpf]

Ich gehe davon aus, dass man aus einem Template keinen Fingerabdruck rekonstruieren kann - stimmt so, oder?

Das kann man nicht - zumindest nicht dass ich wüsste. Vielleicht der Hersteller - aber dieses "Vielleicht" hast Du bei jedem Sensor, der biometrische Daten erfasst.

Du könntest mit diesen Daten einen weiteren R503 Sensor "bespielen" und er würde dann Deinen Finger erkennen. Aber Du könntest nicht damit ein iPhone so modifizieren, dass er Deinen Fingerabdruck erkennt.

Gruß, Waldemar

[AlSae]

Meine Einschätzung zur Sicherheit:

2) Fingerprint darf nicht als Klingel verwendet werden

Kein Einbrecher - und auch niemand zum Spaß -wird lange genug am Fingerprint versuchen reinzukommen. Aber wenn der FP die Klingel ist, ist es einfach statistisch nicht unwahrscheinlich (bei geschätzten 1000-2000 Klingelvorgängen pro Jahr).

Moin,

also nach ein paar Tagen testen, werde ich die Klingelfunktion wieder deaktivieren. Ist im laufenden Betrieb zu träge.
1. Ein Fremder hält nicht "solange" den Finger dran.

2. Obwohl der FP Kinderfinger echt gut erkennt, halten die Kids immer mal n anderen Finger dran und es klingt ständig, Kinder halt.

3. Wenn jemand ohne Schuhe kommt, reagiert der FP nicht.

Gruß Alex

[kleinklausi]

Danke mumpf - ich habe die Tabelle überarbeitet. Wenns nicht passt, bitte nochmal kurz Bescheid geben.

Nachteil, dass sie alles auf eine Stufe stellt, dabei bedingen sich einige der Punkte

Da bin ich bei Dir. Für mich war es wichtig mal alles beisammen zu haben. Ich habe einen Satz vor die Tabelle gestellt.

Das Passwort, dass Du in der ETS eintippst, wird über Direktkommunikation

Spitze! Ist oben angepasst.

Aus der ETS kann das PW direkt nach der Passwortvergabe gelöscht werden, es wird nicht mehr gebraucht.

Ok verstanden und oben ergänzt.

Das ist bereits implementiert und wird mit dem nächsten Update kommen, wenn abtools (Andreas) wieder da ist. Das ist ein erster Schritt, aber nicht unbedingt der letzte.

Eine externe Sperre reicht mir erstmal. Das ganze intern zu lösen, wäre natürlich super!

Ohne Passwort könnte man aus dem ausgebauten Sensor am Rechner die Templates auslesen. Wo liegen hier die Bedenken bzw. das Gefährdungsszenario?

Es wurde im Thread erwähnt, dass man sich gegebenenfalls "unwohl" fühlen könnte, wenn jemand mit seinem Templates wegläuft. Deshalb wollte ich es nicht unterschlagen. Ich gehe davon aus, dass man aus einem Template keinen Fingerabdruck rekonstruieren kann - stimmt so, oder?

Da ich eine Wand zwischen meinem Sensor und der Steuerung habe und ein Passwort setzen kann, habe ich keinerlei Sicherheitsbedenken!

Grüße

[mumpf]

was macht man außerhalb des FP mit den Templates?

Wie gesagt, für mich ist es ein Backup.

Worin besteht der Vorteil des Einspielens von gesicherten Templates gegenüber neuem
Anlernen?

Ganau das: Ich muss nicht neu anlernen. Ich weiß nicht, wie gerne Deine Frau das macht, meine ist da eher schwer dazu zu bewegen.

Solange man mehrere FP in Betrieb hat, sind die ja gegenseitig ein Backup, aber wenn man nur einen hat und der kaputt geht, ist es sicherlich schön, den auch wiederherstellen zu können.

Gruß, Waldemar

[TabSel]

was macht man außerhalb des FP mit den Templates? Worin besteht der Vorteil des Einspielens von gesicherten Templates gegenüber neuem
Anlernen?

[MasterOfPuppets]

+1 fürs template speichern

[mumpf]

Hi kleinklausi,

die Tabelle finde ich gut, sie hat nur den Nachteil, dass sie alles auf eine Stufe stellt, dabei bedingen sich einige der Punkte. Aber es ist besser als gar nichts. Ich muss aber erstmal was korrigieren:

Es gibt eine Idee zu verhindern, dass das Passwort durch eine „Rekonstruktion“ ausgelesen wird.

Das ist bereits implementiert (in 0.2). Das Passwort, dass Du in der ETS eintippst, wird über Direktkommunikation (der Button in der ETS zum PW setzen) und nicht über die normale ETS-Programmierung gesetzt. Dieses PW ist nicht Teil des Parametersatzes, dass während der ETS-Programmierung an das Gerät geschickt wird. Es ist somit nicht durch Rekonstruktion wiederherstellbar.
Auf dem Gerät wird es verschlüsselt gespeichert (Hash) in einem Speicherbereich, der nicht durch die Rekonstruktion erreichbar ist. Außerdem ist das PW aus dem Hash nicht wieder rekonstruierbar.

Das Sensor-Passwort steht immer in der ETS-Projektdatei.

Aus der ETS kann das PW direkt nach der Passwortvergabe gelöscht werden, es wird nicht mehr gebraucht. Es muss nur klar sein, dass es wirklich keiner mehr weiß und weg heißt weg. Ich empfehle eher, das PW in der ETS stehen zu lassen und das ETS-Projekt durch ein PW zu schützen. Dann hat man es wenigstens irgendwo stehen. Ich möchte betonen, dass es kein Sicherheitsproblem ist, wenn das PW in der Projektdatei steht. Denn wenn jemand die Projektdatei hat (und deren PW), dann sind alle anderen Sicherheitsmechanismen, auch KNX Secure, ausgehebelt!

Und noch ein paar Ergänzungen:

Es soll ein KO geben, das verwendet werden kann, wenn der Sensor abgesteckt wird – noch nicht verfügbar

Das ist bereits implementiert und wird mit dem nächsten Update kommen, wenn abtools (Andreas) wieder da ist. Das ist ein erster Schritt, aber nicht unbedingt der letzte. Meine Idee geht eher da hin, nach dem Abstecken des Sensors direkt den FP zu sperren, mit internen Mitteln, und zwar so, dass auch das Stromlos-machen nicht hilft. Man muss erst das Gerät mit der ETS neu proggen, damit es wieder läuft. Ist wie gesagt nur eine Idee, aber würde auch erlauben, die Platine direkt am Sensor zu behalten.

Und bevor das hier wieder erwähnt wird: Wir ist klar, dass alle Maßnahmen ohne KNX Secure nichts bringen. Wann das kommt, kann ich aber nicht sagen, bisher wissen wir noch zu wenig drüber. Es ist also nicht nur "doing", sonder erstmal lernen und ausprobieren - hier ganz klar "open end", keine Abschätzung möglich.

Und noch zum folgenden Punkt für mich aus Interesse:

Ohne Passwort könnte man aus dem ausgebauten Sensor am Rechner die Templates auslesen.

Wo liegen hier die Bedenken bzw. das Gefährdungsszenario?

Ich finde das cool, dass ich endlich an meine Templates komme. Ich werde mir sicherlich bei dem FP eine Funktion bauen, mit der ich die Tepmlates runterladen und als Backup auf dem PC speichern kann (und natürlich auch wiederherstellen kann). Ich finde die Funktion prima und hätte sie auch für andere zur Verfügung gestellt, aber wenn da Bedenken herrschen, dann lasse ich das natürlich sein.

Gruß, Waldemar

[henfri]

Meine Einschätzung zur Sicherheit:
0) Einbrecher kommen ohne Laptop
1) KNX Kommunikation muss Secure sein oder physisch nicht erreichbar
2) Fingerprint darf nicht als Klingel verwendet werden

BTW: Zur FAR: Das muss doch davon abhängen ab welcher "confidence" (die der Sensor ausgibt) man einen Match annimmt. Mir erscheint der Wert recht optimistisch.
Kein Einbrecher - und auch niemand zum Spaß -wird lange genug am Fingerprint versuchen reinzukommen. Aber wenn der FP die Klingel ist, ist es einfach statistisch nicht unwahrscheinlich (bei geschätzten 1000-2000 Klingelvorgängen pro Jahr).

[kleinklausi]

FAR ist mit ≤0.00001% angegeben

Danke MasterOfPuppets. Habe es oben eingefügt.

[MasterOfPuppets]

kleinklausi FAR ist mit ≤0.00001% angegeben.

Ich denke das ding ist jetzt schon absolut ausreichend sicher und bedarf keiner Sicherheitsfeatures mehr....

[kleinklausi]

Hallo, ich habe mal versucht zusammenzufassen, was hier bisher über die Sicherheit geschrieben wurde. Ich wollte für mich eine Risikobewertung. Ich betreibe zwei FP - einen in der Garage für die Nebeneingangstüre und einen abgesetzt an der Garagenaußen- bzw. innenwand für das Tor.

Feedback welcome! Die einzelnen Punkte sind in keiner spezifischen Reihenfolge und bedingen sich teilweise gegenseitig.

Potenzielle Gefährdung	Mögliche Maßnahmen	Zu beachten
KNX-Leitung im Außenbereich	1. Den Fingerprint abgesetzt von der KNX-Steuerung installieren (z.B. Fingerprint Wand-Außenseite und Steuerung auf Wand-innenseite 2. KNX Secure – wird noch nicht unterstützt 3. Virtueller Fingerprint (VFP) - das ist die volle Fingerprint-Applikation, aber ohne Fingerprint-Hardware.	1. Die Verbindung zwischen Fingerprint und Steuerung ist nicht auf lange Leitungen ausgelegt. Eine lange Leitung kann zu unregelmäßigen Fehlerbildern führen. Andreas geht von bis zu 1m aus. Andere haben über geschirmte Cat Leitungen auch schon 9m überbrückt. 2. Andreas und Waldemar sprechen von einer Umsetzung von KNX Secure „mittelfristig“. Hier gibt es keine Abschätzung wann das kommt. 3. Der KNX-Fingerprint schickt nur die ID an den VFP. Das erlaubt die eigentliche Türöffnung aus der Innenlinie zu steuern. Es ist aber immer noch möglich an den VFP beliebiges zu senden.
Tausch des Fingerprint Sensors (Senden einer ID durch einen fremden Sensor)	1. Setze das Passwort in der ETS 2. Ab Release 0.3 wird es ein KO geben, das verwendet werden kann, wenn der Sensor abgesteckt wird.	1. Das Passwort könnte mitgehört werden. Es wird auf der seriellen Schnittstelle im Klartext beim Start der Firmware einmalig übermittelt. 2. Beim Abstecken des Sensors Sicherheitsmaßnahmen ergreifen (z.B. Sperre setzen) 2. Das ist ein erster Schritt, aber nicht unbedingt der letzte. Mögliche Idee: nach dem Abstecken des Sensors direkt den FP intern zu sperren (auch Stromlos-machen würde nicht helfen). Man muss erst das Gerät mit der ETS neu proggen, damit es wieder läuft.
Auslesen der Fingerabdrücke (Templates) aus dem Sensor	1. Setze das Passwort in der ETS	1. Ohne Passwort könnte man aus dem ausgebauten Sensor am Rechner die Templates auslesen.
Bei Finger-Synchronisation gehen die Templates unverschlüsselt über KNX	(benötigt KNX Zugriff) 1. KNX Secure	1. Siehe oben
Auslesen des Passwortes mit der ETS	(benötigt KNX Zugriff) 1. Auslesen des Passwort durch eine Rekonstruktion ist seit Release 0.2 nicht mehr möglich.	1. Das Passwort, dass in der ETS eingegeben wird, wird über Direktkommunikation (der Button in der ETS zum PW setzen) und nicht über die normale ETS-Programmierung gesetzt. Dieses PW ist nicht Teil des Parametersatzes, der während der ETS-Programmierung an das Gerät geschickt wird. Es ist somit nicht durch Rekonstruktion wiederherstellbar. Auf dem Gerät wird es verschlüsselt gespeichert (Hash) in einem Speicherbereich, der nicht durch die Rekonstruktion erreichbar ist. Außerdem ist das PW aus dem Hash nicht wieder rekonstruierbar. 1. Aus der ETS kann das Passwort direkt nach der Passwortvergabe gelöscht werden. Es muss nur klar sein, dass es wirklich keiner mehr weiß; und weg heißt weg. Es wirde eher empfohlen, das Passwort in der ETS stehen zu lassen und das ETS-Projekt durch ein Passwort zu schützen.
False Positives	FAR ist mit ≤0.00001% angegeben

[kleinklausi]

sorry für die Verzögerung

Kein Thema, hattest Du ja sogar angekündigt.

Von 0.1 auf 0.2 gab's leider wie gesagt ein Inkompatibilität

Ja, nach dem Update waren die Namen 'falsch'. Allerdings hatte ich das Problem auch als ich manuell synchronisiert habe - siehe Post #326. Vielleicht kannst Du es Dir anschauen, wenn Du zurück bist.

Grüße Moritz

[abtools]

Hallo kleinklausi und Mabalero,

sorry für die Verzögerung, aber da wie erwähnt aktuell (bis Ende des Monats) in den USA unterwegs, kann ich nicht ganz so häufig hier rein schauen wie sonst. ;-)

Von 0.1 auf 0.2 gab's leider wie gesagt ein Inkompatibilität, aber das sollte künftig nicht mehr vorkommen.
Es wird auf absehbare Zeit künftig alles kompatibel und update-fähig bleiben.

Viele Grüße
Andreas