NFC-Tags steuern FHEM

[ext23]

Du kannst dir ja auch dein RFID Leser selber bauen:

http://www.openpcd.org

Ist vielleicht besser im Internet nach RFID zu suchen anstelle von NFC... beides arbeitet bei 13,56 MHz deswegen kannst du auch mit deinem "NFC" Handy die ganzen Mifare Karten auslesen.

Wegen der Sicherheit sehe ich das so:

Das funktioniert bei Firmenausweisen auch, die geben auch nur ne ID aus und selbst da macht sich kaum einer her und sitzt neben dem Eingang im Auto um deine ID abzufangen. Obwohl es in einer Firma mehr zu holen gibt als bei dir zu Hause ;-)

Ich denke mal wenn man eine Karte mit einer festen ID hat (die kosten ja nichts) und man liest diese mit einem kleinen Leser aus sollte das reichen. Erstmal muss jemand wissen das du deine Tür mit RFID Tags öffnest und dann muss er auch noch wissen auf welchem Wege du das machst. Und gerade bei selbstgebauten Sachen ist sowas schwer. Zumal man den Leser hinter Putz verstecken kann, dann sieht den niemand.

Das ist so ein bissel wie PHP programmieren, programmiert man selber kannst du dir eine Masse Fehler erlauben, aber die lassen sich schwer ausnutzen weil keiner von außen hinter die Kulissen schauen kann. Aber Forensoftware z.B. ist da sehr anfällig weil die im Netz eben verbreitet ist und wenn man den Code kennt kann man auch die Fehler finden um diese dann auszunutzen.

Letztendlich ist es doch eh nur spielerei im normalen privaten Haushalt. Da ist der Schlüssel genauso schnell im Schloss wie die Karte am Leser. Und du wechselst ja nicht alle 2 Wochen deine Reinigunsgkraft der man dann wegen dem Schlüssel hinterherrennen muss. Eindeutiger Vorteil ist hier natürlich die Anwesenheistmeldung, allerdings könnte man das über ein Longrange Reader auch parallel betreiben, ohne das deine Tür damit geöffnet wird.

[henryk]

Moin,

Das bezieht sich sicher auf den Fall, dass beide Seiten miteinander kommunzieren.
In dem Fall hier wird die NFC-ID des passiven Tags lediglich ausgelesen und nicht wieder vom Reader verschickt. Richtig?

Nein, grade nicht. Die diversen APIs und Libraries geben sich zwar alle Mühe, das vor dir zu verstecken, aber NFC oder ISO 14443 sind letztlich doch nur eine Art von Netzwerkprotokoll auf einem Funkmedium. :-)

Ganz, ganz früher (also: sogar bei mir in der Uni ist das jetzt abgebaut, allerdings auch erst letztes Jahr) gab es tatsächlich streng unidirektionales RFID: Das Lesegerät sendet nur einen starken Träger aus welcher das Tag induktiv mit Energie versorgt, und das Tag sendet simpelst am laufenden Bande seine ID, sobald es Energie kriegt. Das war Stand der Technik so ca. Ende der 1980er, mehr konnte man auf einem Tag nicht unterbringen das Kreditkartenformat haben sollte und keine eigene Stromversorgung.
(Irgendwo hab ich auch noch ein Video wie ich da 2006 meine Tür in der Uni geöffnet habe, mit einer Lastmodulationsschaltung aus 4 Bauteilen -- Spule, Kondensator, Transistor und Widerstand -- und einem iPod als Erzeuger für das Datensignal. Umgekehrt ging das auch: ein Detektorempfänger aus Spule, Kondensator und Diode konnte das Datensignal aufzeichnen.)

Alle moderneren Systeme haben eine bidirektionale Kommunikation zwischen 'Lese'gerät und Tag. Das Lesegerät ist eine Art Netzwerkkarte: Es sendet an das Tag Kommandos und das Tag antwortet dann darauf und/oder führt Aktionen (wie etwa Schreibzugriffe) aus -- oder auch nicht. Der Komplexität auf Tag-Seite sind da kaum Grenzen gesetzt, es sind einfach kontaktlose Smartcards die ggbf. auch Java ausführen und im Prinzip alle kryptographischen Protokolle unter der Sonne beherrschen können.

Doch zurück zur Antikollision und NFC-ID: Die Antikollision besteht aus einer Abfolge von Kommandos die im jeweiligen Standard definiert sind. Für ISO 14443 sieht das Beispielhaft so aus:

-- Reader ist im Leerlauf, keine Karte aufgelegt.

• Reader: REQA  (Request Type A, Semantik: Hallo, ist da wer?)
• Reader: REQA
• Reader: REQA

-- Karte wird aufgelegt.

• Reader: REQA
• Karte: ATQA (Answer to Request Type A, Semantik: Ja, bin da. Enthält noch keine weitere Information ausser der UID-Länge)
• Reader: ANTICOLLISION "" (Semantik: Alle Karten deren UID mit "" (also dem leeren Bitstring) beginnt, mal bitte melden)
• Karte: WW XX YY ZZ (Semantik: Enthält die UID)
• Reader: SELECT "WW XX YY ZZ" (Semantik: Karte mit der UID WW XX YY ZZ, du bist selektiert, alle anderen Karten gehen in den Ruhezustand zurück, ANTICOLLISION und SELECT sind das gleiche Kommando und unterscheiden sich fast nur in der Länge des Arguments)
• Karte: SAK (Semantik: Selektion bestätigt)

Der Trick am ganzen hier ist, dass bis zum SELECT-Schritt im Prinzip auch mehrere Karten antworten können: Die Antwortzeiten sind in diesem Teil des Protokolls festgelegt und genau synchronisiert, und die Funkmodulation ist derart, dass wenn mehrere Karten die gleichen Daten senden diese auch korrekt empfangen werden. Zur Antikollision wird das ganze dadurch, dass jede Karte ihre (hoffentlich eindeutige) UID sendet, und der Reader die erste Stelle der Überlagerung finden kann, wenn zwei Karten mit unterschiedliche UIDs antworten. Er schiebt dann einfach soviele ANTICOLLISION-Kommandos dazwischen, wie nötig sind, um genau eine Karte auszuwählen. Das ANTICOLLISION-Kommando kann bitgenau verwendet werden (es geht also auch "Alle Karten deren UID mit den 2 Bytes DE AD gefolgt von den drei Bits 110 beginnt") und der Reader benutzt das um binäre Suche zu machen und alle Stellen wo sich die UIDs von Karten unterscheiden auf einen Wert zu setzen (also zum Beispiel 0).

Zum Abhöhren: Das Funksignal vom Reader ist ziemlich stark, es muss ja die Karte mit Energie versorgen, und wird mit 100% Amplitudenmodulation gesendet. Wenn man einen Empfänger mit externer Stromversorgung hat. ist das problemlos von weit weg zu empfangen. Das Signal von der Karte wird über Lastmodulation gesendet (also die Karte schaltet eine Last, zum Beispiel einen Widerstand, ein und aus, was dann in dem induktiv gekoppelten System Karte-Reader zu einer Rückwirkung führt) und in der Regel schon über die spezifizierten 10cm schlecht zu empfangen. Das aus einem oder mehreren Metern Entfernung noch zu hören ist eher kompliziert, falls überhaupt.

Um nur die UID rauszufinden braucht man das aber gar nicht: Die wird, wie oben zu sehen, im Klartext vom Reader mit aller Kraft durch den Äther geblasen.

--
Henryk Plötz
Grüße aus Berlin

[borsti67]

Um nur die UID rauszufinden braucht man das aber gar nicht: Die wird, wie oben zu sehen, im Klartext vom Reader mit aller Kraft durch den Äther geblasen.

Kurz zusammengefasst, so lange nicht beide Seiten aktiv sind (also eine Kommunikation einleiten, sich auf eine Verschlüsselung einigen und dann erst einen Code senden), ist die Sache prinzipbedingt unsicher, da die ID des passiven Teils während des Scanvorgangs in größerer Entfernung noch mitzuschneiden ist, richtig?
Schade, damit entfällt die Möglichkeit, nur dieses Tag als Schlüssel zu verwenden, was es auch für Dritte einfach nutzbar machen würde - so benötigt man immer irgendeine Software auf dem Gerät. :(

Bei RFID-Tags gilt das gleiche? Das wundert mich, da Du ja schon schriebst, dass viele Firmen das als Zutrittskontrolle nutzen, wenn das "so einfach" nachzumachen ist (ich müsste ja prinzipiell nur einen geeigneten Scanner in der Tasche tragen, während mich jemand ganz offiziell mit seinem Key mit rein nimmt, um mir dann mit der ermittelten ID genau diesen nachzuprogrammieren)?!?

[Martin Haas]

Bei RFID-Tags gilt das gleiche? Das wundert mich, da Du ja schon schriebst, dass viele Firmen das als Zutrittskontrolle nutzen...

Das mit dem Firmenausweis war nicht Henryk.

Wenn man mal nach Henryk Plötz googlet, dann wird man immer wieder über Chaos Computer Club Berlin (CCCB) und seine Vorträge (auch Youtube) zu gerade diesem Thema fündig.

@Henryk: Vielen Dank, dass du hier im Forum so ausgiebig und auch noch toll verständlich dein Fachwissen äußerst!
Grund zu zweifeln habe ich daran nicht ;-))))

[henryk]

Moin,

Kurz zusammengefasst, so lange nicht beide Seiten aktiv sind (also eine Kommunikation einleiten, sich auf eine Verschlüsselung einigen und dann erst einen Code senden), ist die Sache prinzipbedingt unsicher, da die ID des passiven Teils während des Scanvorgangs in größerer Entfernung noch mitzuschneiden ist, richtig?
Schade, damit entfällt die Möglichkeit, nur dieses Tag als Schlüssel zu verwenden, was es auch für Dritte einfach nutzbar machen würde - so benötigt man immer irgendeine Software auf dem Gerät. :(

Da schwingt ein tendentiell falsches Verständnis von "aktiv" mit. Die Aktiv/Passiv-Unterscheidung bei NFC bezieht sich darauf, ob ein Gerät selber ein Feld erzeugt oder nicht. Der hier hauptsächlich wichtige Fall ist "Reader aktiv/Tag passiv" (was bei ISO 14443 der einzige Fall ist). Die andere Unterscheidung die es in NFC noch gibt ist die nach Initiator und Target: Das Funkprotokoll ist streng nach dem "Kommando - Antwort"-Prinzip aufgebaut, und der Initiator ist die Seite die Kommandos sendet. Das alles sagt aber noch nichts über die Fähigkeiten des Tags (auch als passives Target) aus. Die Antikollision ist ja nur der erste Schritt, danach kann noch weitere Kommunikation stattfinden. Auch und grade kryptographische Authentisierungsverfahren die die Echtheit des Tags bestätigen, ohne einfach nur eine ID (oder äquivalent: ein Passwort) zu übertragen.

Was man im Türschlossfall will ist eine mutual authentication: Der Leser an der Tür und das Tag beweisen sich gegenseitig, dass sie ein Geheimnis (einen kryptographischen Schlüssel) kennen, ohne diesen zu übertragen. Wenn man den Schlüssel einfach nur durch die Luft übertragen würde, wäre das ja wie ein Passwort: Jeder der die Kommunikation mitschneiden kann, kann sie auch wieder abspielen. Das kommt doch in ungefähr jedem vierten Detektivfilm vor, dass der Held beobachtet wie jemand unter Benutzung einer Losung durch eine bewachte Tür geht, und dann einfach ebenfalls die Losung benutzt, um durch die Tür zu kommen. Um das zu verhindern benutzt man meist irgendeine Konstruktion derart, dass das Tag eine Zufallszahl an den Leser sendet, der sie mit dem geheimen Schlüssel verschlüsselt zurückschickt (damit ist der Leser authentifiziert) und dann der Leser seinerseits eine Zufallszahl sendet die vom Tag verschlüsselt zurückgesendet wird (damit ist das Tag authentifiziert). Wenn man noch mehr als nur die Echtheit bestätigen will, also zum Beispiel persönliche Daten lesen, siehe Personalausweis/Pass, wird dann die anschließende Übertragung vollständig verschlüsselt so dass die Daten nicht im Klartext durch die Luft gehen.

Grade weil das so wichtig ist, unterstützen viele passive Tags irgendwelche kryptographischen Funktionen. Von den proprietären Mechanismen sind in der Vergangenheit die meisten (lies: alle bei denen sich mal jemand die Zeit genommen hat die anzusehen) gebrochen worden. Zur Zeit würde ich der Kategorie der preiswerten Tags (die Einschränkung ist wichtig, weil man wenn man Geld in die Hand nimmt einfach Java-Karten nehmen kann und dann beliebige Dinge drauf implementieren) für Sicherheitszwecke nur die NXP DESfire EV1 oder die neuen NXP Mifare Plus empfehlen können. Ersteres ist auch, was wir für Firmenkunden machen. Die können dann AES oder 3DES. Leider unterliegt die Doku von NXP einer Vertraulichkeitsvereinbahrung, so dass die Verfügbarkeit von Open-Source-Kompenenten eher *hust* gering ist.

Das wundert mich, da Du ja schon schriebst, dass viele Firmen das als Zutrittskontrolle nutzen, wenn das "so einfach" nachzumachen ist (ich müsste ja prinzipiell nur einen geeigneten Scanner in der Tasche tragen, während mich jemand ganz offiziell mit seinem Key mit rein nimmt, um mir dann mit der ermittelten ID genau diesen nachzuprogrammieren)?!?

In der Tat ist das was viele Firmen als Zutrittskontrollsystem einsetzen eher der Kategorie Spielzeug zuzordnen, und wir arbeiten grade noch daran ihnen zu erklären was sie eigentlich wollen, damit sie es von den Lieferanten verlangen können (die durchschnittlich bis überwiegend keinen blassen Schimmer von elektronischer Sicherheit haben, sind ja schliesslich größtenteils Mechanikschlossfirmen). Nur Verschlüsselung zu haben reicht ja auch nicht, da muss man noch ein paar mehr Gedanken haben (<-Full disclosure: Das ist die Firma für die ich arbeite). Meine Uni zum Beispiel hat jetzt umgestellt auf ein neues System, basierend auf Mifare Classic. Das setzt, wenn man in die Werbebroschüre schaut, ja auch verschlüsselte Übertragungen ein. Trotzdem kann ich alle Türen in der Uni die damit versehen sind öffnen, Kostenpunkt: ~€30 Kartenleser, ~€1 Blanko-Karte, ~5min Arbeit. Im Übrigen hat die Firma die das System vertreibt das natürlich nicht geglaubt (siehe wieder der Punkt, dass die meisten solchen Firmen keine Ahnung von der Sicherheit haben) und ich hab's dann halt der Uni-Verwaltung vorgeführt.

Für den Privateinsatz muss man aber nicht den ganzen Aufwand gehen wie wir das für Firmenkunden tun (unter anderem werden die Masterschlüssel nach dem 4-Augen-Prinzip gesichert und nur auf einem nicht mit dem Netzwerk verbundenen Computer verwaltet), weil man viele der Probleme nicht hat. Im Konzerneinsatz muss ich mir auch überlegen, was ich mache wenn in 5 Jahren ein Lesegerät samt kryptographischem Schlüssel geklaut wird und wie ich aus der Bredouille wieder rauskomme ohne 100.000 neue Mitarbeiterkarten auszugeben (das ist unter anderem was das vorhin verlinkte Whitepaper behandelt), das ist aber bei Privatleuten kein Problem. Hmpf, mich juckt's in den Fingern. Mal gucken was man gegen dieses NDA tun kann.

Bei RFID-Tags gilt das gleiche?

Nochmal spezifisch zu dem Begriff RFID. Ich hab hier vermeidet, den zu verwenden, da er prädestiniert ist, zu Verwirrungen zu führen. "RFID" ist noch viel weniger wohldefiniert als "NFC" (was, wie ich einleitend schon sagte, ein ja doch eher großer Begriffsraum ist). Streng genommen ist "RFID" -- Radio Frequency Identification -- alles was gleichzeitig was mit Funk und Identifikation zu tun hat. Melanie Rieback bringt da dann immer das Beispiel dass eines der ersten RFID-Systeme die Freund-Feind-Erkennung für Flugzeuge im zweiten Weltkrieg war. Ganz so weit benutzt man das im Alltag natürlich nicht, aber trotzdem meinen unterschiedliche Leute mit den vier Buchstaben häufig unterschiedliche Dinge: Das RFID was Walmart für seine Inventur verwendet (EPC Global Gen 2, ~900MHz, Schreib/Lesedaten) hat nichts mit dem RFID für den Impfnachweis für Haustiere zu tun (Verichip, ~130kHz, nur-Lese-ID), was wiederum nichts mit dem elektronischen Personalausweis zu tun hat (ISO 14443-A/B-4, 13.56MHz, hochkomplexes Anwendungsprotokoll mit diversen Zertifikaten und Berechtigungen).

Im Kontext Zutrittsberechtigung hat man es als "RFID" in der Regel mit rund einem Dutzend verschiedener Systeme zu tun, alles passive Tags auf ~130kHz (mehrere proprietäre Funkprotokolle) oder 13.56MHz (ISO 14443, ISO 15693, oder proprietäre Funkprotokolle). Und selbst wenn man sich nur einen Standard anguckt kann man vom Funkprotokoll noch nicht auf die Fähigkeiten des Tags schließen (Mifare Classic und der neue Personalausweis benutzen beide ISO 14443-3, aber mit unterschiedlichen Protokollen in der Schicht darüber).

--
Henryk Plötz
Grüße aus Berlin

[ext23]

He he was du da schreibst kenn ich alles, mangelndes Sicherheitsbewusstsein bei den Firmen, ich komm auch aus dem sec. Bereich ;-)
Und das mit der Uni, naja die netten Kantinenausweise bei denen basieren doch auch nur das super alte Mifare was ehe schon für scriptkiddies hackbar ist oder haben die da schon was Neues? Ich bin da schon seit ein paar Jahren raus, war auf der FHTW...

Nett war ja auch das Thema Auto und Keyless Systeme, die können ja auch alle mit einem simplen funk relay überwunden werden, da gabs doch mal ne reportage zu wo BMW und Co ziemlich blöd aus der Wäsche geschaut hat als testweise die Nobelschlitten "geklaut" wurden ohne auch nur eine Spur zu hinterlassen... Übrigens gabs ein geilen Workaround, den Autoschlüssel in Alufolie versenken, sehr schön...

Für den Privateinsatz muss man aber nicht den ganzen Aufwand gehen wie wir das für Firmenkunden tun (unter anderem werden die Masterschlüssel nach dem 4-Augen-Prinzip gesichert und nur auf einem nicht mit dem Netzwerk verbundenen Computer verwaltet), weil man viele der Probleme nicht hat. Im Konzerneinsatz muss ich mir auch überlegen, was ich mache wenn in 5 Jahren ein Lesegerät samt kryptographischem Schlüssel geklaut wird und wie ich aus der Bredouille wieder rauskomme ohne 100.000 neue Mitarbeiterkarten auszugeben (das ist unter anderem was das vorhin verlinkte Whitepaper behandelt), das ist aber bei Privatleuten kein Problem. Hmpf, mich juckt's in den Fingern. Mal gucken was man gegen dieses NDA tun kann.

Naja stellt man eine schöne PKI hin mit HSM Modul und dann geht da auch kein private key verloren, oder liegen die bei einigen Systeme echt auf dem Reader? Ich mache sowas ähnliches aber auf Mobilfunk beschränkt. Da geht es auch darum was passiert wenn einer mal ne eNodeB (Eine LTE Basisstation) klaut etc. da diese ja auch nur über Ethernet angebunden sind wo ja jeder Mensch mit einem Notebook unterm Arm rann kommt was daher eben verschlüsselt werden muss etc.

Das ist schon alles ein sehr interessantes Thema! Aber ich denke für die Fälle um die es hier geht müssten wir mal wieder ein bissel runterkommen, es sei denn einer will privat ein zweites Fort Knox aufbauen ;-) Allerdings würde ich dann, wenn ich mir sowas bastel auch mit Informationen über das System etwas sparen... Oder man benutzt doch lieber Kontaktbehaftete Systeme.

Gruß
Daniel, auch aus Berlin ;-)

[henryk]

Moin,

Und das mit der Uni, naja die netten Kantinenausweise bei denen basieren doch auch nur das super alte Mifare was ehe schon für scriptkiddies hackbar ist oder haben die da schon was Neues? Ich bin da schon seit ein paar Jahren raus, war auf der FHTW...

Nope, alles noch Mifare Classic. Hat aber wenigstens ein Schattenkonto im Hintergrund, so dass Manipulationen nicht endlos möglich sind.

Naja stellt man eine schöne PKI hin mit HSM Modul und dann geht da auch kein private key verloren, oder liegen die bei einigen Systeme echt auf dem Reader?

Ja, des is ja grad des. Wenn man PKI hätte wäre ja alles viel einfacher. Aber das ist schon genug Aufwand, die Zulieferer dazu zu kriegen, dass sie was AES-basiertes unterstützen. An RSA ist da gar nicht zu denken. Zumal man es dann auch mit deutlich teureren Karten zu tun hätte. Das mit auf dem Reader war natürlich nur vereinfacht gesagt: Der Schlüsselspeicher ist selbstverständlich innerhalb des zu sichernden Bereichs im Controller (der tatsächliche Reader an der Tür macht nur eine Art Medienumsetzer von ISO 14443 auf irgendwas kabelgebundenes) und ist im Hochsicherheitsfall als SAM ausgeführt. Aber auch ein SAM kann prinzipiell abhanden kommen und dann ausgenutzt werden.

Ich mache sowas ähnliches aber auf Mobilfunk beschränkt. Da geht es auch darum was passiert wenn einer mal ne eNodeB (Eine LTE Basisstation) klaut etc. da diese ja auch nur über Ethernet angebunden sind wo ja jeder Mensch mit einem Notebook unterm Arm rann kommt was daher eben verschlüsselt werden muss etc.

Da hab ich neulich einen schönen Vortrag zu gehört: Da die eNodeBs in Massen verbaut werden, gehen sie direkt von der Fabrik an den Einsatzstandort und werden dort lediglich installiert. Alle Konfiguration kommt automatisch aus dem Netz. Nu haben die neuen eNodeBs aber noch kein Schlüsselmaterial, also muss auch das Schlüsselmaterial aus dem Netz gepusht werden. D.h. als Angreifer brauch ich mich nur an das Netz klemmen, behaupten ich wäre eine neue eNodeB und krieg alle nötigen Schlüssel frei Haus geliefert.

Das ist schon alles ein sehr interessantes Thema! Aber ich denke für die Fälle um die es hier geht müssten wir mal wieder ein bissel runterkommen, es sei denn einer will privat ein zweites Fort Knox aufbauen ;-) Allerdings würde ich dann, wenn ich mir sowas bastel auch mit Informationen über das System etwas sparen... Oder man benutzt doch lieber Kontaktbehaftete Systeme.

Genau, zurück zum Anwendungsfall. Ich hab mal in den DESfire-Support von libfreefare reingeschaut. Das sieht prinzipiell vollständig genug aus, um eine Sparversion eines DESfire-basierten Zugangskontrollsystems mit AES zu bauen. Was noch fehlt ist eine Schlüsselableitungsfunktion um UID-abhängige Schlüssel verwenden zu können. Man kann sogar zufällige UIDs auf der Karte einschalten, dann ist sie normal nicht trackbar. 3 Schlüssel würde man benutzen: KMK: Kartenmasterschlüssel (abgeleitet), AMK: Applikationsmasterschlüssel (abgeleitet), AK: Applikationsschlüssel (nicht abgeleitet, nur zum UID lesen).

Der Codefluss um eine Karte (basierend auf einer leeren Karte) zu erzeugen würde in etwa so aussehen:

• UID holen
• Neue Applikation anlegen (

mifare_desfire_create_application_aes()), mit mindestens zwei Schlüsseln, diese Applikation selektieren

Abgeleiteten Applikations-Masterschlüssel AAMK erzeugen aus UID und AMK

Schlüssel schreiben (mifare_desfire_change_key()): AAMK in Slot 0, AK in Slot 1

Karten-Master-Applikation selektieren

Abgeleiteten Kartenmasterschlüssel AKMK erzeugen aus UID und KMK

Schlüssel schreiben: AKMK als Kartenmasterschlüssel

Konfiguration ändern: UID zufällig, nicht frei formatierbar[/list]

Der Codefluss um eine Karte zu authentisieren würde dann so aussehen:

• Applikation selektieren
• Mit AK authentisieren (jetzt ist klar dass die Karte in unser System gehört)
• UID lesen
• Abgeleiteten Applikations-Masterschlüssel AAMK erzeugen aus UID und AMK
• Mit AAMK authentisieren (jetzt ist klar, dass die Karte ist, wer sie vorgibt zu sein)

anschließen kann man die UID (von der jetzt bewiesen ist, dass sie nicht gefälscht ist, weil nur der Leser und die Karte die wir zuvor beschreiben haben den AAMK kennen) benutzen, um seine Zutrittskontrollentscheidung zu treffen.

Der Sicherheitslevel dieses Ansatzes für Angriffe auf die Karten, die Karten-Leser-Kommunikation oder reine Kommunikation mit dem Leser (also wenn der zum Beispiel hinter der Tür ist und der Angreifer ihn nicht physisch manipulieren kann) ist genauso hoch wie alles was wir für Firmen empfehlen (sogar noch höher, weil die zufällige-UID-Spielerei soweit ich weiss noch keiner benutzt), und höher als jedes auf dem Markt verfügbare kommerzielle System. Als mögliche Angriffe (jetzt mal ausgeschlossen Einbruch um an die Schlüssel auf Leserseite zu kommen, dann ist man ja eh drin) bleiben nur noch Relay und Karte klauen (bei weitem am einfachsten).

--
Henryk Plötz
Grüße aus Berlin

[ext23]

Da hab ich neulich einen schönen Vortrag zu gehört: Da die eNodeBs in Massen verbaut werden, gehen sie direkt von der Fabrik an den Einsatzstandort und werden dort lediglich installiert. Alle Konfiguration kommt automatisch aus dem Netz. Nu haben die neuen eNodeBs aber noch kein Schlüsselmaterial, also muss auch das Schlüsselmaterial aus dem Netz gepusht werden. D.h. als Angreifer brauch ich mich nur an das Netz klemmen, behaupten ich wäre eine neue eNodeB und krieg alle nötigen Schlüssel frei Haus geliefert.

Genau das mache ich, nennt sich auch Self-Organizing Networks (SON) in 3GPP, ist ürbigens NSN Vorreiter drin. Aber ganz so einfach ist das nicht, denn die eNodeB's haben ein Fabrik Zertifikat, sonst wäre das ganze ja witzlos. Auf der PKI laufen auch Policies mit, die Seriennummern und sowas mitchecken die zuvor eingepflegt werden etc. doppel IR's gehen auch nicht, also hast auch nur ein Versuch aber naja, keine Details wa, auch hier gilt NDA ;-)

Aber stimmt das ist jetzt etwas OffTopic gewesen, weiter mit dem echten Thema...

[borsti67]

uijeh, da scheine ich ja was losgetreten zu haben. ;)

Erst mal vielen Dank für die ausführlichen Infos, wenngleich teilweise zu hoch für mich (bin mir aber sicher, dass der eine oder andere hier daraus was nützliches entwickeln kann oder gar wird).

Ich bin nun wahrlich nicht versiert und habe auch keine Absicht, sonderlich tief in diese Materie einzusteigen, man möge mir dies nachsehen. Es klang nur nach einer faszinierenden Möglichkeit, die ich mir geringem Aufwand zu nutzen hoffte. Ich versuche mal, das in anderen Worten auszudrücken - auch hier schon vorab die Entschuldigung, dass hier ein Laie schreibt und somit Begriffe falsch oder zu stark vereinfacht rüberkommen dürften...

In der Tat bin ich davon ausgegangen, dass diese NFC-Tags, die man schon so ziemlich überall für kleines Geld kaufen kann, im wesentlichen "nur" aus einer Art von statischer ID bestehen, die entweder hardwareseitig festgelegt ist oder mit einem Programmiergerät definiert werden kann (daher "passiv"). Ein "aktiver" NFC-Part wäre dann eben in der Lage diesen Tag auszulesen und das Ergebnis mittels Software zu irgendwelchen Aktionen zu nutzen.
Meine Idee dahinter wäre gewesen, dass man ein "aktives" Gerät in Türnähe hätte, und seinen Bekannten entweder einen (zuvor freigeschalteten) Kauf-Tag als Schlüsselanhänger überreicht, oder sie zwecks Autorisierung bittet, ihr Handy mal eben zwecks auslesen vorzuhalten (woraufhin man diese nun gelesene ID zu der Öffnungs-Berechtigungs-Liste zufügt).
Wäre meine Aktiv/Passiv-Idee korrekt gewesen, hätte man das so nicht machen dürfen, da die ID durch den Leseprozeß weit genug gesendet wird, dass man die mitschneiden und reproduzieren kann.

Da aber nun die Tags sich doch nicht unbedingt so statisch verhalten, wie ich annahm, müssten ja doch etwas komplexere Authentifizierungen möglich sein? Dennoch wäre mir sehr wichtig, dass der Anwender (also der, der die Tür öffnen möchte) weder vorher irgendeine "App" installieren muss, noch irgendwelche Knöpfe drücken, außer ggf. NFC zu aktivieren, wenn's standardmäßig aus ist... Bzw. dass ich ihm einen fertigen Chip/Aufkleber/... in die Hand drücken kann.

[henryk]

Moin,

In der Tat bin ich davon ausgegangen, dass diese NFC-Tags, die man schon so ziemlich überall für kleines Geld kaufen kann, im wesentlichen "nur" aus einer Art von statischer ID bestehen, die entweder hardwareseitig festgelegt ist oder mit einem Programmiergerät definiert werden kann (daher "passiv"). Ein "aktiver" NFC-Part wäre dann eben in der Lage diesen Tag auszulesen und das Ergebnis mittels Software zu irgendwelchen Aktionen zu nutzen.

Ja, da geht's begrifflich etwas durcheinander. "Aktiv" vs. "Passiv" bezieht sich im RFID/NFC-Kontext darauf, ob die jeweilige Entität eine eigene Stromversorgung hat und zur Kommunikation benutzt (der zweite Teil ist wichtig, weil auch durchaus Komponenten mit eigener Versorgung im NFC-Sinne passiv sein können). Dabei gibt es logischerweise die Kombinationen Aktiv-Passiv und Aktiv-Aktiv. Zweiteres ist nur in NFC (nicht in ISO 14443, was ich mit "RFID" meist meine) drin, und für unsere Betrachtungen weitgehend irrelevant. Aktiv-Passiv ist genau der Teil der Funkübertragung den NFC von vorherigen RFID-Systemen übernommen hat, da können also keine, eine oder beide Seiten im Prinzip zu mehr NFC-Funktionen fähig sein, die sie grade nur nicht nutzen. (Das greif ich gleich nochmal auf.)

Funktionell im FHEM/Heimautomatisierungskontext könnte man sich jetzt vorstellen, unterschieden nach Art der beweglichen und festen Komponenten:

• Aktiver Leser in Türnähe mit Wirkung nach aussen: zum Beispiel ein Leser hinter der Tür, das Feld sollte durch übliche Türen reichen. Oder ein aussen angebrachter Leser mit Kabeldurchführung, wobei man sich da nochmal über die Kabelart unterhalten sollte (aus Sicherheitssicht ist ein ein USB-Anschluss nach aussen dann doch eher mutig). Als Gegenstück werden passive Tags eingesetzt, deren vorbeiführen irgendeine Schaltwirkung nach sich zieht (Alarmanlage unscharf, Tür auf, oder so).
• Passives Tag irgendwo (zum Beispiel Lichtschalter) fest installiert und aktiver Leser als Teil der NFC-Funktionalität im Handy. Vorbeiführen des Tags am Handy führt im Handy irgendeine Aktion aus (zum Beispiel Licht aus/ein an FHEM senden).
• Aktive Komponente fest installiert und aktive NFC-Komponente im Handy. Da fällt mir grade kein Zweck für ein. (Anmerkung: Die NFC-Chips im Handy können auch eine Tag-Emulation, dann ist das aber genau der Fall 1 weil sich das Handy sowohl für NFC- als auch für RFID-Leser wie ein passives Tag verhält.)

Bei 2 ist auf der RFID/NFC-Strecke in erster Näherung keine Sicherung notwendig, da das Vorbeiführen des Tags nur im Handy ein Signal auslöst (genau wie Knopf auf dem Handy drücken) und der eigentliche Zielvorgang (zum Beispiel Licht an/aus) vom Handy irgendwie gemacht werden muss (etwa indem es im richtigen WLAN eingebucht ist, eine telnet-Verbindung zu FHEM aufbaut, und ein Kommando sendet).

Der Fall den ich weitgehend diskutiert habe ist 1, da will man eine verlässliche Sicherung, weil der RFID/NFC-Teil direkt an die jeweilige Aktion gekoppelt ist.

Die Fälle 1 und 2 haben keine Abhängigkeit auf NFC: Das geht genauso wenn eine oder beide Komponenten noch 'nur' ISO 14443 oder einen anderen älteren RFID-Standard implementieren.

... sie zwecks Autorisierung bittet, ihr Handy mal eben zwecks auslesen vorzuhalten (woraufhin man diese nun gelesene ID zu der Öffnungs-Berechtigungs-Liste zufügt).

Das riecht irgendwie nach 3, wo der bewegliche Teil ein aktives Handy ist, das dann aber später vor den unbeweglichen Leser an der Tür gehalten werden soll, damit diese aufgeht. Die üblichen NFC-Handys haben alle eine Tag-Emulation, die in der Regel sogar an ein Sicherheitselement geknüpft ist, um dieselbe Sicherheit wie eine kontaktlose Smartcard (also ein passives Tag) zu erreichen. Technisch übrigens mehr oder weniger indem da einfach nur eine kontaktlose Smartcard fest eingelötet wird. Häufig kommt man als normalsterblicher aber aus Sicherheitsgründen nicht an diese Smartcard ran. Was auch noch geht ist eine Tag-Emulation in Software, etwa das was Google Wallet macht, aber da weiss ich auch nicht genug zu um einschätzen zu können ob das nützlich ist. In jedem Fall degeneriert es zu Fall 1, nur dass das Tag jetzt das Handy ist: 15 mal so dick wie eine normale Karte und 100mal so teuer, ohne funktionellen Mehrwert.

Anyway, ich habe jetzt grade etwas Inspiration eine Sicherheitskomponente a la Fall 1 auf Basis von Mifare Desfire und libfreefare zu bauen, die ich dogfooding-technisch für akzeptabel halten kann (allerdings habe ich keine passenden Aktoren an der Tür, kann es also nicht wirklich einsetzen). Mal gucken wieweit ich komme.

--
Henryk Plötz
Grüße aus Berlin

[Martin Haas]

Anyway, ich habe jetzt grade etwas Inspiration eine Sicherheitskomponente a la Fall 1 auf Basis von Mifare Desfire und libfreefare zu bauen, die ich dogfooding-technisch für akzeptabel halten kann (allerdings habe ich keine passenden Aktoren an der Tür, kann es also nicht wirklich einsetzen). Mal gucken wieweit ich komme.

Die hier bisher aufgezeigte Lösung ist definitiv ein Spielzeug (das habe ich nun auch im Wiki so geschrieben). Vielen mag das ausreichen. Wenn es nicht um sicherheitskritische Dinge geht, dann ist das ja auch ok. Wenn wir hier es nun schaffen eine FHEM-Lösung zu implementieren, die zwar nicht unbedingt Fort-Knox-geeignet ist, aber "dogfooding"-konform ist, ja das wäre toll!!

Das Thema scheint sehr (!) viele zu interessieren. Die Zugriffsraten auf diesen Thread hier sind ja wirklich beeindruckend.

Der FHEM-Geist nach meiner Interpretation mit "ausprobieren, lernen und Spaß haben", wird hier eindrucksvoll gelebt. Wenn jeder nur etwas gemäß seinen Möglichkeiten beiträgt, dann werden wir noch viele tolle Sachen bei FHEM erleben :-)

Martin

[borsti67]

Hallo Henryk,

... sie zwecks Autorisierung bittet, ihr Handy mal eben zwecks auslesen vorzuhalten (woraufhin man diese nun gelesene ID zu der Öffnungs-Berechtigungs-Liste zufügt).

Das riecht irgendwie nach 3, wo der bewegliche Teil ein aktives Handy ist, das dann aber später vor den unbeweglichen Leser an der Tür gehalten werden soll, damit diese aufgeht. Die üblichen NFC-Handys haben alle eine Tag-Emulation, die in der Regel sogar an ein Sicherheitselement geknüpft ist, um dieselbe Sicherheit wie eine kontaktlose Smartcard (also ein passives Tag) zu erreichen. Technisch übrigens mehr oder weniger indem da einfach nur eine kontaktlose Smartcard fest eingelötet wird. Häufig kommt man als normalsterblicher aber aus Sicherheitsgründen nicht an diese Smartcard ran. Was auch noch geht ist eine Tag-Emulation in Software, etwa das was Google Wallet macht, aber da weiss ich auch nicht genug zu um einschätzen zu können ob das nützlich ist. In jedem Fall degeneriert es zu Fall 1, nur dass das Tag jetzt das Handy ist: 15 mal so dick wie eine normale Karte und 100mal so teuer, ohne funktionellen Mehrwert.

Hier war der Hintergedanke ja auch nur, dass man das Handy eh meist mit sich herumschleppt, während man so einen separaten Tag vielleicht gern mal vergisst. ;-)
Aber das ganze wäre eh nur relevant, wenn man ohne extra-Software auf dem Phone auskommt...

Anyway, ich habe jetzt grade etwas Inspiration eine Sicherheitskomponente a la Fall 1 auf Basis von Mifare Desfire und libfreefare zu bauen, die ich dogfooding-technisch für akzeptabel halten kann (allerdings habe ich keine passenden Aktoren an der Tür, kann es also nicht wirklich einsetzen). Mal gucken wieweit ich komme.

Da bin ich ja mal gespannt. ;-)
BTW, Du musst ja (nur zum Ausprobieren) auch keinen Türöffner haben, sondern kannst doch ein beliebiges Gerät schalten (ggf ein Dummy, einfacher vielleicht eine Steckdose mit einer Lampe), um dann zu sehen, ob der Befehl ausgeführt wird oder nicht...?

[Martin Haas]

Gibts die Reader auch nativ-seriell? Dann könnte man sie mit einem CSM verheiraten und direkt von der Türe funken ...

Laut der Kompatibilitätsliste
http://www.libnfc.org/documentation/hardware/compatibility
zur hier verwendeten nfclib sind folgende serielle NFC-Reader verwendbar:
...

Die Homepage wurde zu einem Wiki umgebaut.

Die neue URL zur Kompatibilitätsliste lautet
http://nfc-tools.org/index.php?title=Devices_compatibility_matrix

[henryk]

Moin,

Anyway, ich habe jetzt grade etwas Inspiration eine Sicherheitskomponente a la Fall 1 auf Basis von Mifare Desfire und libfreefare zu bauen, die ich dogfooding-technisch für akzeptabel halten kann

Okay, ich hab da mal was gebaut: https://github.com/henryk/libopenkey
Noch keine FHEM-Integration, aber das ist nur eine Formalität, da kann auch jemand anders ran :)  Bis jetzt gibt es einfach nur die authentisierte ID der vorgehaltenen Karte aus.

Ich hab, wenn ich schonmal dabei bin, zwei Indirektionsebenen eingebaut die eine wesentlich breitere Anwendung ermöglichen. Ich habe mir Mühe gegeben das so zu machen, dass das im hier wichtigen simplen Fall keinen allzugroßen Zusatzaufwand verursacht, aber halt viel toller ist.

Statt der UID/NFCID benutze ich UUIDs, die etwas länger sind, aber dafür nichts mit der UID zu tun haben und trotzdem noch eindeutig sind. Das ermöglicht es auch, mehrere UUIDs auf einer Karte unterzubringen die nichts miteinander zu tun haben. Zu dem Zweck lege ich auf der Karte mehrere Bereiche an, ich nenne sie Slots, die völlig unabhängig sind und unterschiedliche Schlüssel und UUIDs haben. D.h. du kannst die gleiche Karte bei dir zu Hause, in deinem Dackelverein und in deinem Taubenzüchterverein benutzen, wobei jeweils unterschiedliche IDs benutzt werden so dass Logfiles zum Beispiel nicht miteinander verglichen werden können um festzustellen dass das alles die gleiche Karte ist.

Ausserdem hab ich das Anlegen einer Karte und das Verknüpfen einer Karte mit einem/mehreren Schlössern in zwei Prozesse aufgeteilt, die von unterschiedlichen Personen auf unterschiedlichen Rechnern ausgeführt werden können. D.h. du kannst dir deine eigene Karte zu Hause erstellen (dabei werden die UUIDs erstellt und alle Schlüssel auf zufällige Transportschlüssel gesetzt), gehst dann zum Administrator deines Taubenzüchtervereins und gibst ihm die Karte und die Transportschlüsseldatei für einen Slot und er verknüpft diesen Slot mit seinen Schlössern (dabei werden die Schlüssel geändert). Dann gehst du zur Administratorin deines Dackelvereins, übergibst die Karte und die Transportschlüsseldatei für einen anderen Slot und dann verknüpft sie diesen Slot mit ihren Schlössern.

Wenn das Erstellen der Karte erstmal abgeschlossen ist, ist der Funkkanal für Angreifer auch vollständig anonym: An keiner Stelle wird über den Funkkanal etwas unverschlüsselt übertragen, was den Rückschluss auf die UID oder eine UUID einer Karte zulässt. Die normale Benutzung erfordert auch die UID nicht, so dass die Administratoren immer nur die Slot-spezifische UUID sehen. (Allerdings kann man bei DESfire nicht abschalten dass jemand mit dessen Schloss du deine Karte verbunden hast im Prinzip auch die UID abfragen kann. Du musst ihm halt nur vertrauen das nicht zu tun.) Weiterhin ist für einen Angreifer auch nicht ersichtlich, ob und mit welchem Schloss/mit welchen Schlössern deine Karte verbunden wurde, ohne sie zu nehmen und an dem Schloss auszuprobieren. D.h. du kannst deinem Taubenzüchterverein im Prinzip deine Mitgliedschaft im Dackelverein verheimlichen, aber trotzdem die gleiche Karte für beides benutzen.

Bitte um Ausprobieren und Feedback!

--
Henryk Plötz
Grüße aus Berlin

[Martin Haas]

Okay, ich hab da mal was gebaut: https://github.com/henryk/libopenkey

Mann, das ist der Hammer! Ich musste erst einmal eine Stunde nachdenken, um richtig zu kapieren, was Henryk da "mal was gebaut" hat.

Wenn man selbst googlet, merkt man schnell, dass dieser Bereich im OpenSource-Bereich sonst "eher dünn" besiedelt ist.

Seine Einleitung

Code Auswählen Erweitern

This library provides a framework to use NXP DESfire EV1 cards as authentication tokens, e.g. for opening a door, with a security level that equals or exceeds all similar existing systems and some unique anonymity/pseudonymity functions.
lässt erahnen, dass hier in der OpenSource-Scene etwas spannendes geschaffen wird.

Meine bisherigen Mifare-Classic Anhänger kosten ca. 2.-EUR/Stück. Nun werden ich mir die benötigten DESfire EV1-Pendants bestellen (ca. 4 EUR/Stück), um zu versuchen, hier möglichst viel Feedback geben zu können.

Daher wäre es mein Wunsch, wenn möglichst viele hier Henryk Feedback geben könnten. Dabei geht es hier um viel mehr als nur die FHEM-Anbindung -- was das kleinste aller Probleme sein sollte ;-)