[OpenKNX-Ready] Zutrittskontrolle mit Fingerprint / Fingerabdruck

[traxanos]

Die ID hat doch nichts mit Sicherheit zu tun. Ich versuche gerade zu verstehen was du erreichen möchtest.

[henfri]

Der Reader sendet an die Platine nur eine ID.
wenn der Einbrecher (der, der auch die ETS hat, weshalb wir eine getrennte Außenlinie haben und secure wollen) mit einem Fingerprint kommt, an dem er seinen Finger als ID 1 eingelesen hat, dann tauscht er den Reader, legt seinen Finger auf, der FP sendet die 1 und Sesam öffne dich.

[danny]

Unter Fingerabdruckleser -> Allgemein -> Gefährliche Funktionen kannst du ein Passwort für den Fingerscanner eingeben. Mit der Funktion schließt du den Tausch aus. Es gibt nie einen 100% Schutz, aber damit wird er sehr minimiert. Ich habe an die Blende vom Fingerscanner einen Reed gebaut, sobald jemand den Fingerscanner ausbaut schalte ich die Linie aus und er kann machen was er will. Die Linie ist nur wieder von innen einzuschalten. Denke das lässt 99% der Einbrecher es doch über die Fenster und Türen zu versuchen und nicht über ihren PC.

Gruß Danny

[Kampfwurst]

Am besten fände ich wenn es wie bei Ekey eine Option und ein Hardware Kit geben würde bei dem die Verbindung dazwischen verschlüsselt wird.

Sozusagen der Fingerprint mit KNX Secure mit einem 1Reg Device ( Ausgangs Modul mit 2 Relais) auch mit KNX Secure.

[ur63]

Kampfwurst

Irgenwie habe ich den Eindruck, dass nicht verstanden wurde, was die Entwickler von OpenKNX hier und warum bereitstellen.
Kann man als User nicht einfach mal akzeptieren,, dass es sich im übertragenen Sinne um "WYSIWYG" handelt?
Es sei denn, die Entwickler sind der Meinung, es bringt ihrer eigenen Anwendung den nötigen Mehrwert.
Die Sources liegen offen, und somit könnte jeder forken, erweitern und beitragen.

[traxanos]

Am besten fände ich wenn es...

... wenn ich keinen Fingerprint-Reader bräuchte. Einfach eine Kamera die mich 100% erkennt und sieht das meine Hand Richtung Türe geht und schon wird entsperrt


So jetzt mal ehrlich! KNX Data Secure ist im EFH völlig überbewertet. Bevor ich mir die Mühe mache, das Gerät abzuschrauben und durch einen manipulierten Reader mit Fremdfinger zu ersetzten bzw. eigene Steuersignale auf den KNX-Bus zum öffnen der Tür zu geben, schlag ich ein Fenster ein. Wie vor einem Jahr bei einem Bekannten (übrigens Dicht besiedelt). Nachbarn haben es gehört und niemanden hat es interessiert. Die waren fast 10min (was wohl schon recht lang ist) in der Wohnung und haben alles auf den Kopf gestellt.


KNX Data Secure ist wichtig für öffentliche Gebäude wie z.B. Hotels!

Der Fingerprint R502 ist jetzt auch nicht der Hochsicherheitsfingerprintreader. Also wenn man sich darüber gedanken macht, dann ist ggf der FP hier das falsche Produkt.

[henfri]

Hallo,

so, jetzt wird es etwas emotional, aber da müsst ihr durch

Irgenwie habe ich den Eindruck, dass nicht verstanden wurde, was die Entwickler von OpenKNX hier und warum bereitstellen.
Kann man als User nicht einfach mal akzeptieren,, dass es sich im übertragenen Sinne um "WYSIWYG" handelt?
Es sei denn, die Entwickler sind der Meinung, es bringt ihrer eigenen Anwendung den nötigen Mehrwert.
Die Sources liegen offen, und somit könnte jeder forken, erweitern und beitragen.

Ich weiß echt nicht, was das soll (vielleicht die EDOMI Krankheit?).
Ich habe hier den Hinweis gegeben, dass fast alles selbsterklärend ist (super!) mir aber für wenige Punkte die Dokumentation fehlt.
Turns out: Die gibt es, aber sie ist nicht verlinkt. Ist doch super. Jetzt weiß Andre, dass der Link an zwei Stellen (Github-Seite und Post #1) helfen würde.

Dabei nehme ich ein Beispiel, welches Waldemar wenige Posts vorher (allerdings untereinem anderen Begriff) erklärt hat und ihm gefällt nicht, dass ich nicht wenigstens die eine Seite gelesen habe. Kann ich verstehen, stört mich auch manchmal, aber ich hatte doch gar nicht die Frage, wie der Modus geht, sondern es war nur ein Beispiel.

Soweit so gut, damit kann ich leben.
Irgendwann wurden wir dann wieder sachlich und es ging um meinen Vorschlag, die Nummern zu randomisieren. Den Vorschlag hat Andre aufgenommen. Was er daraus macht, ist ihm überlassen. Ich fordere da garnix und ich profitiere nicht davon. Auch denke ich, dass der Nutzen noch diskutiert werden sollte, bevor das umgesetzt wird.

Beruflich werde ich für meine Auffassungsgabe und Ideenreichtum geschätzt. Den bringe ich auch gerne hier im Forum ein. Als ich in einem Nebensatz bemerkte, dass ich von Smarthome/Smartvisu auf HA umsteige fand einer der tollsten Entwickler ( AndreK ) das schade und hat genau das zum Ausdruck gebracht (und das Feedback hat mich sehr gefreut und motiviert): Ich hab zwar nicht viel zu Code beigesteuert, aber gute Ideen. Wo starten denn "die Entwickler"? Sind das nur die, die Code schreiben, oder auch die, die sich vielleicht Gedanken um Security oder UI machen und Feedback geben?

Zudem: Ich habe ja sogar angeboten, dass ich es umsetzen kann.
Gestern noch habe ich meinen PR zum Fingerprint mit abtools besprochen, der weitere Hardware unterstützt und jetzt im Dev-Zweig ist.

Für den SEN-UP1 habe ich vorgeschlagen die PIO Funktionen zu nutzen (da sind wir wieder: Ideen sind auch ein Beitrag), um Lesefehler im 1w Bereich zu vermeiden/reduzieren, da ein User darüber klagte. In dem Thread habe ich mich auch Inhaltlich eingebracht um das Kernteam bei Supportaufgaben zu unterstützen.
Jetzt findet Dominik den Vorschlag eine gute Idee, hat aber keine Zeit ihn umzusetzen. Also hab ich es gemacht. Aber mir fehlt die Hardware. Die habe ich gestern bestellt. Dazu sei gesagt, dass ich keinen Plan habe, 1w mit OpenKNX zu nutzen. Es geht mir nur darum, etwas zurück zu geben.

Aber dass ich hier auch mit Code unterstütze soll nicht bedeuten, dass man nicht auch ohne Code mit Ideen beitragen kann.

Wie auch immer. Ich halte mich dann jetzt zurück, wenn das gewünscht ist.

Gruß,
Hendrik

[mumpf]

Trotzdem werde ich noch Data Secure dafür machen. Aber nicht weil alle es wollen, sondern weil es mich interessiert und ich es spannend finde. Und weil ich es schon mal auf testweise hinbekommen habe.

Allerdings ist es ein langer Weg von einem "zusammengeschusterten" Versuch bis zu etwas, dass auch von anderen genutzt werden kann. Denn was wir ganz sicher nicht machen werden: Jedes Gerät bei uns in Betrieb nehmen, damit wir einen Schlüssel vergeben und einen Aufkleber drucken, wie es bei den Herstellergeräten läuft. Hier wird also auch jeder selbst tätig werden müssen, und es wird auch anders laufen, als man es von Herstellern gewohnt ist. Es muss dann eben klar sein, dass eine Secure-Inbetriebnahme aufwändiger wird. Alleine die Software, die den User dann bei der Inbetriebnahme unterstützt, ist noch nicht mal begonnen...

Gruß, Waldemar

[Ing-Dom]

so, jetzt wird es etwas emotional, aber da müsst ihr durch

Hendrik, ich zumindest hatte die Antwort von ur63 auf den Vorschlag von Kampfwurst bezogen, nicht auf deine Vorschläge.

Ich schätze deine Beiträge (PRs und auch Ideen).

[ur63]

ich zumindest hatte die Antwort von ur63 auf den Vorschlag von Kampfwurst bezogen, nicht auf deine Vorschläge.

Korrekt, hätte ich einleitend schreiben sollen...ergänzt.

[mumpf]

Hallo Hendrik henfri,

danke für Deinen "emotionalen" Kommentar. Es war nicht mein Ziel, gute Ideen zu unterdrücken oder abzubügeln. Ich versuche nach bestem Wissen und Gewissen möglichst sachlich und fachgerecht zu antworten, wer meine Beträge kennt, wird mir hoffentlich zustimmen. Und wenn mir das manchmal misslingt, dann bin ich gerne bereit, mit zu entschuldigen, ich bin auch "nur" ein Mensch.

Ich hatte die letzten Tage den Eindruck, dass die Qualität Deiner Beiträge nachgelassen hat und Du eher schnell eine Frage getippt als nachgelesen/nachgedacht hast. Natürlich ist das subjektiv und potentiell falsch. Du bist für mich ein sehr erfahrener User mit viel wissen, Du bist länger dabei als ich. Und Du machst auch qualitätsvolle Beiträge - deswegen hab ich z.B. bei Deiner Frage nach Gruppenmonitor und mehrere Antworten im Diagnosemodus ("die ETS dekodiert nur den letzten") etwas sarkastisch geantwortet, denn die Frage war unter Deinem Niveau (das ist als Kompliment gemeint und nur ein Beispiel, um meinen Eindruck zu belegen).

Entschuldige bitte, wenn ich Dir Unrecht getan habe, ich möchte nicht, dass Deine Ideen verloren gehen, auch wenn sie nicht alle realisiert werden können.

Gruß, Waldemar

[traxanos]

Trotzdem werde ich noch Data Secure dafür machen.

Spricht ja auch nichts dagegen. Aber ich mag diese Pesudosicherheit nicht. Geht mir im Beruf schon täglich auf den ... . Randomisierte Fingerprint-IDs z.B. bringen 0,0 erhöhen aber die Komplexität unnötig. Verschlüsselte Kommunikation mit dem FP, bedeutet das der FP so einen Modus aus unterstützen muss. Dann muss der kram auch wieder entschlüsselt werden. Ist ja nicht so als hätten wir großen i7 mit AES support als HW Platform. (Vom sicheren Keyexchange mal abgesehen)

Und das sollte auch allen klar sein. Und zumindest bei meinem Beitrag geht es um Aufklärung. Ich werbe immer wieder gerne für einen Perspektivwechsel!

Wie auch immer. Ich halte mich dann jetzt zurück, wenn das gewünscht ist.

Nein sinnvolle Diskussion sind gut. Aber leider wiederholen sich Themen immer wieder und dann wird es auch etwas lästig. Weil wir wollen lieber Software entwickeln statt immer die gleichen Themen zu besprechen.

[henfri]

Hallo,

Hendrik, ich zumindest hatte die Antwort von ur63 auf den Vorschlag von Kampfwurst bezogen, nicht auf deine Vorschläge.

Verstehe. Aber der arme Kerl weiß doch wahrscheinlich gar nicht, dass das mit dieser Hardware nicht möglich ist.
Man hätte also stattdessen antworten können:
Kampfwurst: Kennst du eine erschwingliche und verfügbare Hardware, die das unterstützt?

Unter Fingerabdruckleser -> Allgemein -> Gefährliche Funktionen kannst du ein Passwort für den Fingerscanner eingeben. Mit der Funktion schließt du den Tausch aus.

FYI: Das Setzen des Passworts verhindert m.W. nicht den von mir genannten Angriffsvektor, da die Kommunikation weiter unverschlüsselt stattfindet. Es verhindert nur das anlernen (und andere administrative Funktionen, die mit dem PW gesichert sind)
Diesen Vektor könnte man - wenn man ihn für relevant hält; ich nicht sonderlich - schützen, indem man
- die Arbeit einstellt bis XYZ, wenn der FP abgesteckt wird (es gibt ja schon ein KO dafür und man kann darüber den Aktor sperren)
- Security by Obscurity: zufälligere IDs verwendet
- ggf. weitere.
Aber eine Verschlüsselung ist aus meiner Sicht dafür im Wohngebäude nicht angemessen, falls es keinen günstigen, verfügbaren Sensor mit entsprechender Soft und Hardwareunterstützung gibt.

mumpf Verstehe, danke. Alles gut.

traxanos

Spricht ja auch nichts dagegen. Aber ich mag diese Pesudosicherheit nicht. Geht mir im Beruf schon täglich auf den ... . Randomisierte Fingerprint-IDs z.B. bringen 0,0 erhöhen aber die Komplexität unnötig.

Das kann man nur bewerten, wenn man das Angriffsscenario kennt. Ich wette, ich komme hier bei fast jedem Nutzer des Fingerprints rein, wenn ich auf die Platine zugreifen kann. Und zwar innerhalb von wenigen Minuten. Und das ohne ETS.
Mit zufälligen IDs würde mir das kaum noch gelingen.

Ist ja nicht so als hätten wir großen i7 mit AES support als HW Platform

Ich glaube nicht, dass die Datenmenge zu entschlüsseln die aktuelle HW überfordern würde.
Dennoch ist es unverhältnismäßig, v.a. beim aktuellen Reader wie du schon sagst nicht möglich.

Hier hatte doch jemand mal eine Liste der möglichen Schwächen und Workarounds zusammengestellt. Die wäre etwas für die Doku.
Edit: es war kleinklausi hier https://knx-user-forum.de/forum/proj...72#post1962872

Gruß,
Hendrik

[traxanos]

Das kann man nur bewerten, wenn man das Angriffsscenario kennt. Ich wette, ich komme hier bei fast jedem Nutzer des Fingerprints rein, wenn ich auf die Platine zugreifen kann. Und zwar innerhalb von wenigen Minuten. Und das ohne ETS.

Wenn du auf die Platine kommst, kommst du auch an den KNX Bus. Und wenn du an die Platine kommst, kämmst du sogar an den SecureKey (wenn wir das mal implementiert haben) Wir haben keine Secureenclave! Die IDs spielen keine Rolle. Ich kann die einfach alle kurz durch gehen. Dann müsstet du schon mit sowas wie UUIDs arbeiten.

Das Setzen des Passworts verhindert nicht den von mir genannten Angriffsvektor, da die Kommunikation weiter unverschlüsselt stattfindet.

so ist es.

die Arbeit einstellt bis XYZ, wenn der FP abgesteckt wird

naja ganz so einfach ist es nicht. wann ist das gerät abgesteckt? wenn ich 1s oder 100ms nicht mehr mit dem gerät gesprochen habe. und was ist wenn ich mit einfach laufend einklinke. ist gibt ja keine sabotage überwachung.

Security by Obscurity: zufälligere IDs verwendet

nein bring es nicht. der range ist klein und man könnte ihn schnell durchlaufen.

Aber eine Verschlüsselung ist aus meiner Sicht dafür im Wohngebäude nicht angemessen, falls es keinen günstigen, verfügbaren Sensor mit entsprechender Soft und Hardwareunterstützung gibt.

so sieht es aus. wenn der sensor sowas bieten würde, wäre die diskussion obsolete weil es "recht einfach" um zu setzen wäre. man müsste schauen wie sich die entschlüsselung auf die vorhanden laufzeit auswirken. es verlngsamt die verarbeitung der anderen module etc.

Ich glaube nicht, dass die Datenmenge zu entschlüsseln die aktuelle HW überfordern würde.

darum geht es nicht. wir arbeiten hier embedded. laufzeiten vom loop haben erheblichen einfluss auf die funktionen. das ganze ist ja nicht eventdriven mit prioritäten etc.

Dennoch ist es unverhältnismäßig

dass ist das was ich zum schluss meinte. wenn jemand darauf wert setzt, dann ist das ggf nicht das richtig produkt. wie gesagt dann erwarte ich aber auch das alles min RC4 ist Und eine Alarmanlage inkl Waschutzanbindung verbaut wurde

[henfri]

Hallo,

es geht ja immer um das Verhältnis zw. Aufwand auf der einen Seite (Einbrecher) und der anderen Seite (Entwickler).
Einen FP bei dem ich ID 1-10 mit meinen Fingern eingelesen habe stecke ich nullkommanix um.
Eine Software, die alle IDs durchprobiert und das Protokoll des FP liest habe *ich* nicht schnell umgesetzt.
Auch das laufende einklinken ist nicht einfach (an die Drähtchen kommen, ohne sie zu zerstören). Aber sicher machbar.

Wie gesagt: Eine Frage dessen, was man für realistisch hält. Ich kann gut damit leben, wenn wir zum Schluss kommen, dass der Einbrecher keine ETS und keinen eigenen Sensor mitbringt.
Trotzdem verwende ich nicht ID1-10 :-)

Hier noch ein PR für die Doku:
https://github.com/OpenKNX/OAM-Fingerprint/pull/3

Gruß,
Hendrik