[OpenKNX-Ready] Zutrittskontrolle mit Fingerprint / Fingerabdruck

[Theees]

Ich würd das Oszi nehmen und damit die Scheibe einwerfen

Btw. der einzige vor dem ich wirklich Angst habe ist abtools denn er hat das Gerät schliesslich entwickelt und weiss wo wir ALLE wohnen

ironie.gif

Bin immernoch total begeistert von dem Gerät. Funktioniert besser als der FP in meinem 4K€ Arbeitslaptop

[traxanos]

Danke einer hat es verstanden!!!

[klayman]

Findet Ihr das nicht etwas absurd? Den Einbrecher möchte ich sehen der mit Laptop, Oszilloskop und Logikanalyzer den Fingerprint abschraubt, die Kommunikation belauscht um während der Initialisierung das Passwort abzufangen. Dann dieses in einen neuen Fingerprint zu schreiben (wofür man auch wieder Hardware braucht), den dann anzustecken um dann schlussendlich ins Haus zu kommen. Wer so schlau ist und auch noch das ganze Equipment hat ist entweder ein Profi-Einbrecher (den interessiert dann aber nicht unsere kleine Hütte) oder hat es schlicht und einfach nicht nötig. Habt Ihr alle durchwurfhemmende Scheiben? RC4-Beschläge? Keinen Schlüssel in der Garage versteckt? Ich würd das Oszi nehmen und damit die Scheibe einwerfen oder Euch mit nem 9mm Meinungsverstärker auflauern...

Long story short: Jedes Extra-Feature ist doch wieder eine mögliche Fehlerquelle. Sollte man nicht zwischen Kosten und Nutzen abwägen? Just my 2 cents ;-)

[martinhoefling]

Ein Risiko was hier immer wieder diskutiert wurde ist das Ersetzen mit einem anderen FP Reader des gleichen Modells. Hierfür gibt es ja auch schon ein KO falls ein Reader getrennt wurde.

Hat schonmal jemand über das Notepad Feature des Readers (doc) nachgedacht, um das Modul zu (re-)authentifizieren? (PS_WriteNotepad and PS_Read Notepad)

Das setzen eines Passworts authentifiziert den Host gegenüber dem Reader nach der Initialisierung. Als Ergänzung dazu sollte das lesen des Notepads und Vergleich mit einem bekannten Token verwendet werden können, um den Reader gegenüber dem Host initial, z.B. nach einer Trennung, zu authentifizieren. Oder habe ich etwas übersehen?

Das schützt natürlich nicht vor Angriffen auf die laufende Kommunikation insbesondere während der Initialisierung. Aber es ermöglicht die re-Initialisierung eines vormalig vertrauten FP Readers, z.B. nach einem Stromausfall.

[traxanos]

gelöscht - kein bock auf die diskussionen. macht was ihr wollt damit ihr besser schlafen könnt. auch placebos haben ihre daseins berechtigung

[abtools]

Hallo zusammen,

zumindest kann diese Idee nicht schaden und ist in der Tat einfach umzusetzen:
Vermutlich ein zusätzliches KO, was geschrieben wird, wenn eine unbekannte ID gescannt wurde. Dann kann jeder selbst entscheiden, ob er diese Info verwendet und, wenn ja, was er damit macht (z. B. den Fingerprint sperren).

Ich nehm's mal auf die ToDo für das nächste Update! :-)

Aber wie bereits im Thread geschrieben, haben wir ja bereits eine Überwachung, die erkennen sollte, wenn der Fingerprint abgesteckt und gegen einen/etwas anderes getauscht wurde. Wenn es jemand also schafft diese Überwachung irgendwie zu umgehen, dann glaube ich hilft auch die Erkennung einer unbekannten ID nicht mehr. Aber wie gesagt, schaden kann's auf jeden Fall trotzdem nicht.

Ansonsten, wie bereits oft geschrieben
Ein 100 % sicheres System wird es nicht geben und am Ende gehen die Einbrechen dann doch einfach durch's Fenster anstatt mit Notebook am Fingerprint "rumzubasteln". :-)

Wir tun aber unser Möglichstes, um es den Leute zumindest schwerer zu machen und ja, auch KNX Secure wird mittelfristig noch kommen, wie Waldemar bereits erwähnt hat.

Vielleicht können wir's dabei dann mit dieser Diskussion erst einmal belassen.

Viele Grüße
Andreas

[IPv6]

Vielleicht kannst du mir erklären was du so schlimm daran findest, ein bestehendes System mit sehr überschaubarem Softwareaufwand noch ein bisschen sicherer zu machen? Es verlangt doch niemand, dass das sofort jetzt bitte auf der Stelle umgesetzt werden soll.
Es sind einfach nur Vorschläge und Ideen, was man tun könnte wenn man denn wollte und Zeit und Lust hätte.

Ich halte die Wahrscheinlichkeit für einen solchen Angriff auch für fast ausgeschlossen und plane, das System genau so wie es ist einzusetzen.
Aber ich neige halt dazu, Dinge immer weiter verbessern zu wollen - Spieltrieb des Ingenieurs oder so?

Natürlich ist das bekannt, ist ja nicht so als hätten wir keine Ahnung was wir tun.

Also zumindest zum Zeitpunkt meines Vorschlags war die Idee noch neu.
Und gestern hast du noch argumentiert, dass das nichts bringen würde.

[traxanos]

Die Hardware müsste bloß bei der ersten unbekannten, vom R503 gesendeten ID dicht machen.

Doof das ich meinen FP am Schreibtisch an einer anderen HW angelernt habe. Aber ja das wäre eine Option. Ich würde das aber nicht umsetzen, bin aber auch nicht der Autor. Und es ist immer noch mit Kanonen auf Spatzen. Ich frag mich die gnaze Zeit, wenn euch das alles zu unsicher ist, warum zur Hölle nutzt ihr dann das System?

Das hatte ich so auch schonmal mit Andreas besprochen, als wir uns getroffen hatten, ist ihm also bekannt und hätte eine Chance, umgesetzt zu werden.

Natürlich ist das bekannt, ist ja nicht so als hätten wir keine Ahnung was wir tun.

[overkill]

Die Hardware müsste bloß bei der ersten unbekannten, vom R503 gesendeten ID dicht machen.

Sehr clevere Idee und sollte eigentlich auch recht einfach zu implementieren sein, würde ich (ohne Hintergrundwissen) mal vermuten!

[IPv6]

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

Das ist einfach nur einen Schritt zu kurz gedacht.
Die Hardware müsste bloß bei der ersten unbekannten, vom R503 gesendeten ID dicht machen.
Da die Hardware im Normalbetrieb immer den R503 anlernt, weiß sie genau, welche IDs es gibt. Unbekannte IDs würde nur ein fremder R503 (oder eine entsprechende Softwareemulation) senden.

Der R503 speichert 500 IDs, im Normalfall dürften davon so etwa 5 in Verwendung sein. Reduziert also deine Chance, beim Senden einer zufälligen ID einen gültigen Treffer zu landen, auf 1 %. Eine zweite Chance nach einer falschen ID hast du nicht, wenn nach einer unbekannten ID gesperrt wird.

Das hatte ich so auch schonmal mit Andreas besprochen, als wir uns getroffen hatten, ist ihm also bekannt und hätte eine Chance, umgesetzt zu werden.

[traxanos]

Sicherheit ist in meinen Augen nie absolut, sondern relativ

so ist es.

Und es ist in meinen Augen besser, den Vektor zu verkleinern

wenn es sinnvoll ist. es ist immer ein abwägen von interessen und wahrscheinlichkeiten.

Ist eine ähnliche Diskussion wie "brauchen wir AFDD".

aber ich habe auch keine dezidierte Außenlinie

hab ich auch nicht


Das eigentlich Problem an der Diskussion ist, dass es keine Diskussion unter paar Experten ist die eine Abwägung durchführen, sondern das hier ist ein öffentliches Forum, dass ggf. auch Leute unnötig verunsichert. Vor allem weil das gleiche Thema immer und immer wieder aufkommt. Die Leute können die Aussagen von uns nicht ins Verhältnis setzen. Daran sollte man auch etwas denken.


Fassen wir also das Ganze nochmal zusammen. Der Fingerprint ist keine Hochsicherheitslösung. Das System ist manipulierbar wie vermutlich alle Fenster und Türen in einem EFH Haus. Braucht jemand besondere Sicherheit muss er sich ein anderes System zulegen und ggf kombiniert mit einer echten Alarmanlage und dazu passenden physichen Einbruchschutz.

[henfri]

Der Kreis derer, die dein Szenario beherrschen ist sicher um einen Faktor 10-100 kleiner, als der Kreis den mein Szenario beherrschen.
Sicherheit ist in meinen Augen nie absolut, sondern relativ. Und es ist in meinen Augen besser, den Vektor zu verkleinern, als das zu lassen, nur weil der Vektor dadurch nicht vollständig geschlossen ist.
Aber nochmal: ich halte auch mein Szenario für unwahrscheinlich genug (aber ich habe auch keine dezidierte Außenlinie )

Damit ist jetzt von meiner Seite dazu genug gesagt.

Gruß,
Hendrik

[traxanos]

mit meinen Fingern eingelesen habe stecke ich nullkommanix um

1) ob ich einen anderen fingerprintreader anstecke oder ein kleines arduniodevice mit entsprechender software ist vom aufwand soweit gleich
2) um dein szenario bescheibt einen gezielten angriff gegen dich! ist ja nicht so das jedes zweite haus ein R503 an der Türe hängen hat Also wenn du angst davor hast das dich explizit einer mit vorbereitung angreift, glaubst du das du ihn davon abhältst weil du die IDs radom vergeben hast
3) ich hab 1-10 z.b. garnicht in verwendung. aber nicht wegen der pseudosicherheit sonder aus organisatorischen gründen. warum geht man überhaupt davon aus das es per se 1-10 bei jedem ist.

Aber das Tolle ist ja. Wenn es dich besser schlaffen lässt, vergibt die IDs zufällig

[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

[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