NFC-Tags steuern FHEM

[Martin Haas]

Ein Wiki-Eintrag wird folgen. Hier vorab mal Infos. Evtl. hat ja jemand das Rad schon erfunden und ich mache mir die Arbeit umsonst.

Seit dem ich entdeckt habe, dass mein Nexus 4 prima mit NFC arbeitet :-), soll das auch als Anweisung für FHEM gehen.
Der umgekehrte Weg, also das Handy schaltet über das Internet meine Sachen, ist natürlich einfach (z.B. APP NFC Launcher).

Spannend wird es, wenn man mit jedem 2.-EUR-NFC-Tag irgendwas schalten kann. Angeblich soll das sicher genug sein, um auch die HM Keymatic der Haustüre und die Alarmanlage zu schalten. Das muss jeder für sich selbst entscheiden, da muss man auch das Gesamtkonzept sehen (ein Button "Haustüre auf" im Frontend ist wenig hilfreich).

Den Beitrag erstelle ich hier im RASPI-Bereich, weil diese Kiste ideal dafür geeignet ist. Auch kann mein Wiki-Eintrag dann noch gezielter erfolgen. Evtl. will man ja wirklich vor der Haustüre einen USB-Card-Reader per USB-Kabel montieren. Da biete es sich an, so einen zusätzlichen billigen RPI mit WLAN im USB-Kabel-Bereich zu verlegen.
Natürlich läuft das auch auf jedem anderen Linux-PC, allerdings nicht auf der Fritzbox (auf der aber FHEM laufen kann).

Nochmal: Details folgen im Wiki, hier soll es um einen ersten Überblick gehen.
Los geht es:
-- wir brauchen einen mit Debian Wheezy laufenden Rasperry Pi
-- eine NFC-USB-Reader (hier SCM SCL3711). Vorsicht, es gehen nicht alle, SCL3711 läuft bei mir.
-- Netzwerkanbindung an FHEM (falls FHEM nicht auch auf dem RPI, sondern auf z.B. einer Fritzbox läuft)
-- libnfc-1.6.0-rc1 aus dem Internet mit Bauanleitung (nicht schwer
-- Benötige Debian-Module wie pcscd und andere


Nach dem Bau der libnfc folgendes in eine neue /etc/modprobe.d/blacklist-libnfc.conf schreiben:

Code Auswählen Erweitern


#/etc/modprobe.d/blacklist-libnfc.conf
blacklist pn533
blacklist nfc



Ein kleines BASH-Script in z.B. /usr/local/bin/nfc2fhem.sh

Code Auswählen Erweitern


#!/bin/bash

#Skript, das die NFCID eines NFC-TAGS ausliest und an FHEM schickt
#Dies ist bisher nur ein Testaufbau

# muss je nach fhem.cfg nicht lokal sein.
FhemIP="192.168.0.x"

#ob die NFCID ausreichend ist, muss noch geprüft werden.
while true
do
        NFCID="$(nfc-list | grep NFCID)"
        [[ $NFCID != '' ]] &&  {
                NFCID="$( echo $NFCID | cut -d":" -f2 | sed "s/ //g")"
                echo "$NFCID found"
                echo "set $NFCID toggle" | nc -w5 $FhemIP 7072
                                }
        sleep 3
done


Fehlerprüfungen etc. fehlen noch. Natürlich gibt es noch andere und wohl auch bessere Wege.


Und nun noch ein Eintrag in der fhem.cfg:

Code Auswählen Erweitern


#Ein mit "nfc-list" erkannter NFC-Tag sieht z.B. so aus: 02ec8ee9
#NFC-Tag Test
define 02ec8ee9 dummy
define nfcnot1 notify 02ec8ee9 set HM_Sw_01 toggle

Man kann also alles aufrufen, auch Logiken und andere Programme -- funktioniert :-)


Alles weitere (inkl eingearbeitetem Feedback ;-) ) dann im Wiki...

Ein Modul zu erstellen, wäre zwar mein Wunsch, aber so recht weiss ich nicht, wo ich da ansetzen soll.

Am Rande: das PERL CPAN NFC-Reader-Modul habe ich auf dem RPI nicht zum Laufen gebracht.

[Martin Haas]

Ein Beitrag im Wiki ist nun erstellt:
http://www.fhemwiki.de/wiki/Raspberry_Pi_%26_NFC

Abgeschlossen ist das Projekt noch nicht, insofern wird es noch Änderungen und Ergänzungen geben.


Auch soll ein NFC-Reader auf Basis des RPi an die Haustüre (was ich damit so alles schalte, weiß ich noch nicht), evtl. gibt es dann noch Bilder und Basteltipps.

[borsti67]

Auch soll ein NFC-Reader auf Basis des RPi an die Haustüre

So einen mehr-oder-weniger kompletten NFC-Reader gibt offenbar nicht, oder?
Die Idee finde ich ja äußerst spannend, und vermutlich besser/flexibler als den umgekehrten Weg (also ein NFC-Tag an der Tür anbringen und das Smartphone aufgrund dessen einen Schaltbefehl ausführen lassen).
Aber eigentlich möchte ich nicht noch einen weiteren Rechner "nur dafür" haben. Leider habe ich Reader nur als USB-Modelle vorgefunden, und ob ich ein USB-Kabel von meiner Syno bis zur Tür kriege, wage ich zu bezweifeln (abgesehen davon, dass ich auch nicht weiß, ob die DiskStation damit was anfangen kann)... :-(

[tostmann]

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

[Martin Haas]

Aber eigentlich möchte ich nicht noch einen weiteren Rechner "nur dafür" haben.

Das ist ja das geniale an der RPi. Jede Waschmaschine/Kaffeemaschine/Gadget kann quasi mit einer RPi oder ähnlichem kostengünstig bestückt werden. Insofern sind um uns herum ganz viele "weitere Rechner" verbaut.
Ein "fertiger" NFC-Reader kann auch mit sowas gebaut werden (wäre eine Geschäftsidee). So eine RPi ist ein klasse Universal-"Gehirn" für alle möglichen Geräte, wie auch Roboter und eben auch einen NFC-Reader :-)
Billiger sind fertige Geräte, wenn es sie überhaupt zu kaufen gibt, auch nicht unbedingt.

So finde ich es gut, dass der hier vorgestellte NFC2FHEM-Reader autark agiert, also kein FHEM-Modul benötigt.

Also im Idealfall sieht man den NFC2FHEM-Reader als eine Einheit an und nicht als einen "weiteren Rechner".

Ist auf jeden Fall eine tolle Spielwiese :-)

[Prof. Dr. Peter Henning]

Da gibt es nur einen Haken: Der RPi ist leider für sicherheitskritische Aufgaben noch nicht stabil genug :-(( Das ist keine persönliche Meinung, sondern die Quintessenz der entsprechenden Foren.

Sehen wir das doch mal etwas abstrakter:

Das Entstehen einer "digitalen Ökologie" habe ich schon vor 13 Jahren in einem Buch vorhergesagt. Wir sind in der Wissenschaft aber der Ansicht, dass die Systeme, mit denen das realisierbar ist, sehr viel einfacher werden sein als ein Raspberry. Das schließt zwar unerwartete Effekte in größeren Netzen keinesfalls aus - sichert aber immerhin die Beherrschbarkeit der einzelnen Knoten des Netzes.

Etwas konkreter:

Ein NFC-Reader zur Zugangskontrolle sollte möglichst einfach sein. Eine Anbindung über Funk klingt zwar interessant - steht aber im Widerspruch zur NFC-Idee. Betrachten wir das an Hand einer WLAN-Anbindung: So könnte ich beispielsweise auch vor der Haustür das Smartphone im WLAN anmelden, und per VPN einen Öffnungsbefehl an die Haustür senden, damit ist der NFC-Teil vollkommen überflüssig.

LG

pah

[borsti67]

Aber eigentlich möchte ich nicht noch einen weiteren Rechner "nur dafür" haben.

Das ist ja das geniale an der RPi. Jede Waschmaschine/Kaffeemaschine/Gadget kann quasi mit einer RPi oder ähnlichem kostengünstig bestückt werden.

Hinter "kostengünstig" würde ich noch mal ein Fragezeichen setzen. ;-)
Von der Konfiguration - als nicht-Linux-Freak - mal ganz abgesehen, leider.

[borsti67]

Ein NFC-Reader zur Zugangskontrolle sollte möglichst einfach sein. Eine Anbindung über Funk klingt zwar interessant - steht aber im Widerspruch zur NFC-Idee. Betrachten wir das an Hand einer WLAN-Anbindung: So könnte ich beispielsweise auch vor der Haustür das Smartphone im WLAN anmelden, und per VPN einen Öffnungsbefehl an die Haustür senden, damit ist der NFC-Teil vollkommen überflüssig.

Das würde ich nun wieder nicht unterschreiben, wenn wir mal den Faktor "Komfort" nicht vernachlässigen.
Zum einen möchte ich nicht, dass der Haustüröffner jedes Mal betätigt wird, wenn ich in die Nähe meines WLANs komme (nur wenn ich direkt vor der Tür stehe), zum anderen möchte ich nicht am Smartphone irgendwas groß herumdrücken müssen. Wenn ich das mit NFC richtig verstanden habe, würde "Handy vor den Sensor halten" ausreichen, um den Summer zu starten (vorausgesetzt, NFC ist ständig aktiviert), während ich für irgendwelche Befehlseingaben zumindest irgendein Widget o.ä. auf dem Homescreen haben müsste, welches ich bei Bedarf drücke - also im günstigsten Fall Handy entsperren und Button drücken.

[Martin Haas]

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

Für die Antwort musste ich erst mal recherchieren ;-)

Zur CSM fällt mir nur adafruit ein:
http://www.adafruit.com/blog/2012/08/03/tutorial-adafruit-nfcrfid-on-raspberry-pi-piday-raspberrypi-raspberry_pi/

Von nativen seriellen NFC-Readern habe ich gelesen, einen Link finde ich aber nicht mehr. Erfahrungen diesbezüglich kann ich auch nicht vorweisen.

Von dir setze ich aktuell eine CUN und ein CUNO ein, insofern sehe ich durchaus Sinn in einer NFC-Kombinaton mit der CSM. Für mich als Linuxer bevorzuge ich mehr die konservative Seite mit Standardhardware und -befehlen.

[Martin Haas]

Hallo pah,

Da gibt es nur einen Haken: Der RPi ist leider für sicherheitskritische Aufgaben noch nicht stabil genug :-((

hier möchte ich dir ausdrücklich NICHT widersprechen.

Seit vielen Jahren bin ich ja bei fhem dabei (schade, dass mir meine hunderte Postings in der Google-Group aus technischen Gründen hier nicht gutgeschrieben werden). Der eine oder andere kann sich noch an mein pgm3 erinnern.

95 Prozent meiner recht grossen Anlage bestehen noch aus FS20-Komponenten. Richtig stabil war das alles nie, mal wurde der eine Rolladen "vergessen" mal ging das andere nicht. Spaß macht das alles, meine Frau muss da weniger darüber lachen ;-)

Dieser neue nfc2fhem-Reader ist in meinem Aufbau bisher absolut stabil. Ob ich damit nun professionell "sicherheitskritische Aufgaben" schalten würde, ist eine andere Sache. Dem Geist von diesem FHEM-Projekt (nach meiner Interpretation) mit ausprobieren, lernen und Spaß haben entspricht das allemal. Auch lächeln muss ich gerade über meine Einleitung in meiner 99_ALARM.pm (liegt im contrib-Ordner): "this is a toy...."

Ich denke mal, du würdest dich über so einen gewissen Spieltrieb deiner Studenten freuen. Aber auch gut, dass du mit dem wissenschaftlichen Zeigefinger mal einhakst :-)

Viele Grüße,
Martin

[Martin Haas]

Ein NFC-Reader zur Zugangskontrolle sollte möglichst einfach sein. Eine Anbindung über Funk klingt zwar interessant - steht aber im Widerspruch zur NFC-Idee. Betrachten wir das an Hand einer WLAN-Anbindung: So könnte ich beispielsweise auch vor der Haustür das Smartphone im WLAN anmelden, und per VPN einen Öffnungsbefehl an die Haustür senden, damit ist der NFC-Teil vollkommen überflüssig.

Soweit in der Theorie. Auch wenn es im Widerspruch zur NFC-Idee stehen sollte: in meiner 5-köpfigen Familie habe nur ich ein NFC-Smartphone. Auch der Frau zuzutrauen eine VPN-Verbindung aufzubauen, um die Türe nach 1min zu öffnen ist nicht praxisgerecht.
Weiterhin ist ein Lesezeichen "Türe auf" auch nicht ungefährlich.

Nein, die Idee NFC-Aufkleber in alle Familienhandys einzukleben und Schlüsselanhänger zu verteilen hat schon was.

Als Backup sollte ein "Hardware"-Schlüssel irgendwo tief im Garten begraben sein.

Ausdrücklich: jeder muss für sich selbst entscheiden, ob die Sicherheit für sich selbst ausreichend ist.

[Prof. Dr. Peter Henning]

Gerne - aber den Spieltrieb habe ich auch selber und versuche, ihn den Studenten beizubringen.

LG

pah

[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:

http://www.adafruit.com/products/364

und
APDB1UA33N
http://www.arygon.de/images/stories/produkte-oem-reader/HF-Reader/Mobile/NFC_MIFARE_MOBILE_MODULE_APDAB_16.pdf

Der hier angeblich auch, hat aber einen anderen Treiber (nicht PN532, den nfc-list benötigt). Da wäre ich vorsichtig.
APDB2UA33
http://www.arygon.de/images/stories/produkte-oem-reader/HF-Reader/PlugnPlay/NFC_MIFARE_PLUG_N_PLAY_MODULE_APPAB_16.pdf

Das wäre doch was für http://www.busware.de ;-)

[henryk]

Moin,

Zur Sicherheit ...

Angeblich soll das sicher genug sein, um auch die HM Keymatic der Haustüre und die Alarmanlage zu schalten.
[...]
#ob die NFCID ausreichend ist, muss noch geprüft werden.

... muss ich mal ein bisschen ausholen.

NFC ist ein äusserst unscharfer Begriff für eine Reihe von Standards und Definitionen. Unter anderem definiert es ein Funkprotokoll für Kurzstreckenkommunikation (bis 10cm) welches (nicht ganz zufällig) kompatibel zum älteren ISO 14443 ist. Das Funkprotokoll dient erstmal nur zum Erkennen und Aktivieren von Tags (in 14443 sind immer ein aktiv sendender Reader und ein oder mehrere passiv antwortende Tags enthalten, in NFC können auch beide Seiten aktiv sein) und erlaubt dann den Austausch von Kommando-Antwort-Paaren. Dazu kommen dann in NFC noch Definitionen von Tag-Typen (das war in ISO 14443 nicht enthalten, da kochte jeder Hersteller sein eigenes Süppchen) mit spezifizierten Kommandos und Verhalten (in der Regel identisch oder kompatibel zu existierenden proprietären Hersteller-Typen, eins davon ist zum Beispiel fast 1:1 NXP Mifare Ultralight, ohne jedoch je die Worte "NXP" oder "Ultralight" in den Mund zu nehmen). Auf dieser Basis aufbauend definiert NFC dann ein Nachrichtenformat (NDEF), Nachrichtentypen und -Semantik, zum Beispiel für Smart Poster ("Rufe URL ... im Browser auf") oder Visitenkarten ("Füge einen neuen Eintrag mit folgenden Daten in's Adressbuch ein: ..."). An keiner Stelle definiert NFC irgendwas was mit Sicherheit oder Verschlüsselung zu tun hat. (Naja, fast, Lockbits die das Überschreiben von Inhalten auf Tags verhindern sind wenn ich mich richtig erinnere vorgesehen.)

Da fragt man sich: Die Deutsche Bahn macht doch jetzt zum Beispiel Touch&Travel und das soll sicher sein und das ist doch auch NFC oder nicht? Also muss NFC doch sicher sein? Ja...in. Der NFC-Kern-Anwendungszweck (NDEF-Nachrichten auf passiven Tags speichern) ist weiterhin unbeeinflusst von jeglichen Sicherheitsbemühungen. Was man macht, ist nur das Funkprotokoll zu benutzen um eine bidirektionale Kommunikation hinzukriegen und alles weitere darüber zu regeln. Alle Anwendungen die irgendwas mit Sicherheit zu tun haben (Touch&Travel, Personalausweis, etc.) benutzen nur diesen Teil von NFC (was also auch mit ISO 14443 schon geht) und wickeln ihre Sicherheitsbedürfnisse selbst ab (mit AES oder RSA oder so). (Bzw. die Touchpoints der Bahn haben tatsächlich noch eine NFC-Nachricht integriert mit der Semantik "Starte die Touch&Travel-Applikation der Bahn", aber mehr auch nicht.)

Was die NFCID angeht: Früher hiess das UID und ist (bei ISO 14443-A bzw. kompatiblen, gibt auch ein paar andere Standards die alle ungefähr das gleiche leisten, sich aber in Details unterscheiden, und üblicherweise von allen NFC-fähigen Geräten unterstützt werden) eine 4-, 7- oder 10-byte lange hoffentlich eindeutige Nummer. (Obacht: Die Nummerngasse 08 XX XX XX ist für zufällige UIDs reserviert die bei jedem Auflegen des Tags wechseln.) Die UID ist ein zentraler Bestandteil des Funkprotokolls und der Antikollision (ist dafür da, damit der Reader auch funktioniert, wenn man eine Geldbörse mit mehr als einem Tag auflegt, weil er sagen kann "Tag mit der UID x ist jetzt dran, alle anderen halten die Klappe"), kommt also schon sehr früh im gesamten Protokolllauf zum Tragen.

Und ist natürlich vollständig ungesichert. Die meisten kommerziell hergestellten ISO-14443- oder NFC-fähigen Komponenten ergreifen Maßnahmen um sicherzustellen, dass die UID eindeutig bleibt (auf Tags kann man sie in der Regel nicht überschreiben, auf NFC-Komponenten im passiven Tag-Emulationsmodus ist das erste Byte auf 08 fixiert), aber das dient mehr der Robustheit und ist nicht als Sicherheitsmaßnahme zu verstehen. Es gibt in Asien Händler die für ~$40 das Stück Mifare-Classic-Tags (ISO 14443-A) anbieten auf denen man die UID ändern kann. Bastler-Hardware ist natürlich erst Recht frei darin, eine UID nach ihren Wünschen auszugeben. Prominentestes Beispiel im RFID-Forschungsumfeld ist der Proxmark III für rund ~$100-200, aber es gibt auch noch einige andere Tag-Emulatoren die das können.

Beispiel: Dieses Video zeigt wie ich einen Schlüsselschrank bei mir in der Uni aufmache, der nur auf die UID der vorgehaltenen Karte reagiert. Das ist umso erschreckender da ich die Hardware die ich verwende (OpenPICC, theoretisch so ~€40) nie richtig zum funktionieren gebracht hab: Empfangen ging nicht ordentlich, nur Senden. Der Empfangsteil konnte nur ungefähr die Länge des einkommenden Kommandos schätzen, aber nicht den genauen Inhalt. Das hat trotzdem gereicht, um eine beliebige UID vorzutäuschen.

Evtl. will man ja wirklich vor der Haustüre einen USB-Card-Reader per USB-Kabel montieren.

Das ist aus sicherheitstechnischer Sicht eine ganz schlechte Idee. Da spare ich mir als Angreifer dann die Funkemulation und nehme einfach einen USB-Emulator. Travis Goodspeed hat da grade viel Spaß mit seinem USB-Emulator und bricht der Reihe nach alle möglichen Dinge die sich auf das genaue Verhalten von USB-Geräten verlassen.

Im Übrigen muss man meine Ausführungen natürlich im Kontext sehen. Persönlich würde ich nichts auch nur annähernd derartiges für meine Tür verwenden, Berufskrankheit. :-) Wenn man dann aber am Ende doch nur einen FS20-Schalter betätigt, ist die NFC-UID eine gute Größenordnung schwerer zu fälschen, als einfach das FS20-Signal direkt zu senden.

Und, ja, man muss auch erstmal an die zu fälschende UID rankommen. Das stellt sich aber als relativ einfach heraus: Wie oben geschrieben wird die ja bei jeder Transaktion vom Reader gesendet. Und im Gegensatz zum passiven Tag kann man den aktiven Reader problemlos in mehreren (dutzend?) Metern Umkreis empfangen.

Gibts die Reader auch nativ-seriell?

libnfc ist, dem Namen zum trotz, erstmal größtenteils eine Library um den NXP PN53x und Verwandte anzusteuern (das steht in der Tradition der älteren librfid die eigentlich nur den NXP RC632 ansprach). Es gibt viele Wege zum PN53x und modernerweise will man natürlich etwas USB-basiertes. Der PN533 hat ein USB-Interface direkt integriert und braucht nur wenig externe Beschaltung. Der PN532 (welches die häufigste Variante ist) unterstützt SPI, I2C und, ja, auch RS-232.

Die meisten PN532-basierten Produkte die man kaufen kann, haben einen USB-Anschluss und eine interne Umsetzung: entweder per USB-RS232-Konverter, irgendwie Huckepack über USB (der Touchatag zum Beispiel ist ein kontaktbasierter Smartcardleser, bei dem manche Kommandos abgezweigt werden und an den PN532 gehen statt an die Smartcard), oder mit einem internen Stack so dass sie über USB wie ein kontaktbasierter RFID-Leser wirken und den entsprechenden Standard implementieren.
D.h. wenn du libnfc und nicht USB nutzen willst, gibt es die Kombination im Prinzip und du kannst dir sogar statt RS-232 ein anderes Protokoll wünschen (OpenPCD 2 zum Beispiel verwendet SPI). Ich erinnere mich dunkel dass wir für einen Kunden, im Zusammenhang mit libnfc, schonmal einen Arygon-Leser erfolgreich verwendet haben (allerdings mit USB-RS232-Konverter, wer hat heute schon noch RS232 an seinem Laptop?).

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

[Martin Haas]

Vielen Dank für die sehr umfangreiche und verständliche Erklärung über den Hintergrund der Technik. Ich habe lange im Internet recherchiert, aber nicht auch nur annährend so etwas gefunden.
Ich habe diesen Artikel im Wiki mit verlinkt.

Folgendes habe ich nicht verstanden:

Und, ja, man muss auch erstmal an die zu fälschende UID rankommen. Das stellt sich aber als relativ einfach heraus: Wie oben geschrieben wird die ja bei jeder Transaktion vom Reader gesendet. Und im Gegensatz zum passiven Tag kann man den aktiven Reader problemlos in mehreren (dutzend?) Metern Umkreis empfangen.

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?
Dass sie über das Netzwerk (verschlüsseltes WLAN oder Kupfer) an FHEM geschickt wird, sollte aus NFC-Sicht unkritisch sein.

Viele Grüße,
Martin