FHEM Forum

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:

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



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

#!/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:


#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.

Ein Beitrag im Wiki ist nun erstellt:
http://www.fhemwiki.de/wiki/Raspberry_Pi_%26_NFC (//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.

Zitat von: Martin Haas schrieb am Sa, 19 Januar 2013 22:29Auch 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)... :-(

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

Zitat von: borsti67 schrieb am So, 20 Januar 2013 14:50Aber 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 :-)

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

Zitat von: Martin Haas schrieb am So, 20 Januar 2013 15:25

Zitat von: borsti67 schrieb am So, 20 Januar 2013 14:50Aber 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.

Zitat von: Prof. Dr. Peter Henning schrieb am So, 20 Januar 2013 16:45Ein 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.

Zitat von: tostmann schrieb am So, 20 Januar 2013 15:08Gibts 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.

Hallo pah,

Zitat von: Prof. Dr. Peter Henning schrieb am So, 20 Januar 2013 16:45Da 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

Zitat von: Prof. Dr. Peter Henning schrieb am So, 20 Januar 2013 16:45Ein 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.

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

LG

pah

Zitat von: tostmann schrieb am So, 20 Januar 2013 15:08Gibts 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 ;-)

Moin,

Zur Sicherheit ...

Zitat von: Martin Haas schrieb am Mi, 16 Januar 2013 20:07Angeblich 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.

Zitat von: Martin Haas schrieb am Mi, 16 Januar 2013 20:07Evtl. 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.

Zitat von: tostmann schriebGibts 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

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:

Zitat von: henryk schrieb am Fr, 25 Januar 2013 05:08Und, 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

Du kannst dir ja auch dein RFID Leser selber bauen:

http://www.openpcd.org (//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.

Moin,

Zitat von: Martin Haas schrieb am Fr, 25 Januar 2013 09:36Das 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

Zitat von: henryk schrieb am Fr, 25 Januar 2013 10:33Um 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)?!?

Zitat von: borsti67 schrieb am Fr, 25 Januar 2013 19:41Bei 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 ;-))))

Moin,

Zitat von: borsti67 schrieb am Fr, 25 Januar 2013 19:41Kurz 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.

Zitat von: borsti67 schrieb am Fr, 25 Januar 2013 19:41Das 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.

Zitat von: borsti67 schrieb am Fr, 25 Januar 2013 19:41Bei 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

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...

ZitatFü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 ;-)

Moin,

Zitat von: ext23 schrieb am Sa, 26 Januar 2013 09:25Und 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.

Zitat von: ext23 schrieb am Sa, 26 Januar 2013 09:25Naja 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.

Zitat von: ext23 schrieb am Sa, 26 Januar 2013 09:25Ich 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.

Zitat von: ext23 schrieb am Sa, 26 Januar 2013 09:25Das 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

ZitatDa 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...

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.

Moin,

Zitat von: borsti67 schrieb am Sa, 26 Januar 2013 19:08In 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.

Zitat von: borsti67 schrieb am Sa, 26 Januar 2013 19:08... 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

Zitat von: henryk schrieb am So, 27 Januar 2013 00:11Anyway, 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

Hallo Henryk,

Zitat von: henryk schrieb am So, 27 Januar 2013 00:11

Zitat von: borsti67 schrieb am Sa, 26 Januar 2013 19:08... 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...

ZitatAnyway, 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...?

Zitat von: Martin Haas schrieb am Do, 24 Januar 2013 16:41

Zitat von: tostmann schrieb am So, 20 Januar 2013 15:08Gibts 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

Moin,

Zitat von: henryk schrieb am So, 27 Januar 2013 00:11Anyway, 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

Zitat von: henryk schrieb am So, 03 Februar 2013 05:02Okay, 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
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 ;-)

Klingt interessant ja, schau ich mir mal an wenn Zeit ist. Muss nur mal checken ob einer meiner USB RFID Reader die ich noch im Schrank habe damit laufen...

Zitat von: henryk schrieb am So, 03 Februar 2013 05:02Okay, ich hab da mal was gebaut: https://github.com/henryk/libopenkey

Die Seite ist gerade nicht mehr da (Fehler 404). Mal hoffen, dass es da keine schweren Probleme gibt.

Meine DESFire EV1-Karten kommen wohl erst morgen, aber bis hier ist alles erstaunlich glatt verlaufen. Für Beginner sicher eine Herausforderung ;-), aber sonst alles kein Hexenwerk.
Bisher sieht alles toll aus :-)
root@raspberrypi:~# openkey-producer openkey_secrets my_card
Note: Bootstrapping card producer role and generating secret keys
This may take some time ...
No card to initialize found
Also warten wir mal gespannt auf die Kartenlieferung morgen :-)

Moin,

Zitat von: Martin Haas schrieb am Mo, 04 Februar 2013 19:00Die Seite ist gerade nicht mehr da (Fehler 404). Mal hoffen, dass es da keine schweren Probleme gibt.

Ja, sorry, ich hab das grade mal (hoffentlich vorübergehend) weggenommen, da mein Chef mich darauf hinwies dass es nicht nur darum geht, die NXP-NDA de facto nicht zu verletzen, sondern auch dafür zu sorgen, dass NXP gegenüber nichtmal der Anschein entsteht, ich/wir könnten sie verletzt haben. Also doch erstmal Rücksprache mit NXP halten, da hab ich wohl etwas schnell geschossen.

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

Hallo

Ich bin noch neu im NFC Thema. Hatte mir kürzlich verschiedene Tags zum Ausprobieren gekauft, u.a. auch eine Desfire EV1. Bin dann über diesen Thread gestolpert. Ist ja genial, was hier geschieht!!!! (Und tierischer Respekt vor Henry!!!)

Habe das jetzt mal alles auf meinem Ubuntu-PC ausprobiert. Läuft soweit ganz gut :-)

Hatte allerdings beim openkey-authenticator ein paar seltsame Effekte. So hatte ich es zweimal, dass sich irgendwas im Prozess aufgehängt hat. Oder eher noch im Reader. Zumindest war er nach dem Abbruch des openkey-authenticators nicht mehr erreichbar und musste abgezogen und wieder angeschlossen werden. Einmal hatte ich beim Abbruch des openkey-authenticators sogar eine Kernel Panic.

Eine Noobie-Frage habe ich noch: Die Karte ist nach der Initialisierung durch den openkey-producer ja mit den Schlüsseln gesperrt. Wie könnte ich die Karte noch einmal komplett löschen? Oder geht das gar nicht mehr?

Michael

Hmm, nach dem Durchlesen der echt guten Doku von Henryk scheint es mir, als ob man die Karten auch wieder komplett löschen können müsste. Man muss "nur" den richtigen PICC-Key berechnen.

Ich kriege es aber nicht richtig hin. Habe jetzt einige Stunden probiert, "mifare-desfire-format" so zu ändern, dass es den Key richtig berechnet. Kriege aber keine Authentification hin. Kann mir jemand auf die Sprünge helfen, wo mein Fehler liegt? (Datei ist attached).

Übrigens scheint es mir so, dass Henryks code keine Karten mit Random UID akzeptiert. Weiss jemand, warum das so ist? Sollte doch eigentlich kein Hindernisgrund sein, oder? Das würde ja bedeuten, dass man eine Karte, nachdem man sie einmal mit openkey benutzt hat und dann wieder neuformattiert hat, nicht mehr benutzen kann.

Übrigens habe ich immer noch ein paar Probleme mit dem openkey-authenticator. Die LED auf dem Lesegerät flackert die ganze Zeit und eine Kartenidentifikation kann zwischen 1 und 10 Sekunden dauern oder auch gar nicht klappen. Zwischendurch schmiert das ACR122u dann noch ab und ist erst nach ausstecken/einstecken wieder erreichbar. Also noch nicht so ganz einsatzfähig. :-(

Softwaretechnisch kann ich leider nicht helfen.

Auch bei meinem SCM SCL3711 habe ich ähnliche Erfahrungen gemacht. Also Ein-/Ausstecken war notwendig usw. Es funktioniert also noch nicht.

Hierzu hatte ich mit Henryk Mailkontakt. Er berichtete, dass er mit seinem "touchatag über pcscd an libnfc" offenbar nur wenige Kinderkrankheiten hat und es prinzipiell läuft.
Ja, bei mir liegen jetzt auch drei eingerichtete Desfire EV1 - Karten herum, die ich bislang auch nicht löschen konnte.

Bei mir läuft die im Wiki beschriebene Variante mit dem Auslesen der NFCID (was mit den neu formatierten Karten nicht mehr geht, da sie nun Random-Antworten liefern).

Wäre toll, wenn das libopenkey irgendwann auch mit meinem SCM SCL3711 und auch deinem ACR122u stabil laufen würde.

Hat jemand die libopenkey-Lösung im Einsatz und wenn ja mit welchem NFC-Device?

Übrigens ist die Akzeptanz von NFC bei der Family nicht überragend, nun kommt zusätzlich ein Zahlenschloss vor die Tür :-)
Link (http://forum.fhem.de/index.php?topic=11521.msg67529#msg67529)

Zitat von: Martin Haas schrieb am Do, 07 März 2013 16:45Softwaretechnisch kann ich leider nicht helfen.

Hmm, ich vermute mal, dass da Henryk am besten geeignet sein sollte. Vermutlich ist das eine Sache von zwei Minuten für ihn.

Kannst Du den Post vielleicht zu ihm weiterleiten? Oder mir seine Email per PM senden?

ZitatAuch bei meinem SCM SCL3711 habe ich ähnliche Erfahrungen gemacht. Also Ein-/Ausstecken war notwendig usw. Es funktioniert also noch nicht.
Hierzu hatte ich mit Henryk Mailkontakt. Er berichtete, dass er mit seinem "touchatag über pcscd an libnfc" offenbar nur wenige Kinderkrankheiten hat und es prinzipiell läuft.

Könnte vielleicht eine Kernel oder libusb Sache sein. Ich hatte ja sogar einmal eine Kernel Panic. Vielleicht sollten wir ihn mal fragen, was für eine exakte Konfiguration sein System hat (also Kernel, Libusb, etc).

Nutzt er denn den ACR122_pcsc Treiber oder den ACR122_usb?

ZitatJa, bei mir liegen jetzt auch drei eingerichtete Desfire EV1 - Karten herum, die ich bislang auch nicht löschen konnte.

Also meiner (unerfahrenen) Meinung nach müsste das auf jeden Fall gehen. Man braucht nur den richtigen Key, der aber aus dem Master-Key und der Random UID berechnet wird.

ZitatBei mir läuft die im Wiki beschriebene Variante mit dem Auslesen der NFCID (was mit den neu formatierten Karten nicht mehr geht, da sie nun Random-Antworten liefern).

Ich weiss nicht, ob man die Karten nach Formattierung wieder auf feste UIDs zurückstellen kann. Glaube, mal gelesen zu haben, dass das nicht ginge. Aber nutzen könnte man die Karten dann auf jeden Fall noch, am besten  Prinzipiell auch wieder mit openkey.

ZitatWäre toll, wenn das libopenkey irgendwann auch mit meinem SCM SCL3711 und auch deinem ACR122u stabil laufen würde.

+1 :-)

ZitatÜbrigens ist die Akzeptanz von NFC bei der Family nicht überragend, nun kommt zusätzlich ein Zahlenschloss vor die Tür :-)
Link

Schade, warum denn nicht?

P.S.: Trage übrigens seit fast 10 Jahren eine Junghans-Uhr mit integriertem Mifare-Chip. Habe jetzt mal die Schlüssel geknackt und kann den Chip endlich mal verwenden...

Zitat von: Neuer_User schrieb am Do, 07 März 2013 18:22Hmm, ich vermute mal, dass da Henryk am besten geeignet sein sollte. Vermutlich ist das eine Sache von zwei Minuten für ihn.

Kannst Du den Post vielleicht zu ihm weiterleiten? Oder mir seine Email per PM senden?

Henryk bekommt genauso wie du immer eine Benachrichtigung, wenn hier neue Posts eingehen. Insofern hoffe ich ja noch, dass er sich meldet.
User haben hier das Recht ihre Mailadresse zu verbergen, wenn sie wollen -- das respektiere ich.
Als angemeldeter Nutzer sollte es dir offenstehen, nach Klick auf seinen Namen hier ihm ein PM-Nachricht zukommen zu lassen (das habe ich auch so gemacht).
Am Rande: einfach mal googlen, ich war total überrascht wie oft (mit Mailadresse) ich ihn im Internet gefunden habe.

ZitatNutzt er denn den ACR122_pcsc Treiber oder den ACR122_usb?

Weiss ich nicht. Mein letzter Mailkontakt mit ihm war am 12. Februar, evtl. gibt es ja Fortschritte.

ZitatAlso meiner (unerfahrenen) Meinung nach müsste das auf jeden Fall gehen. Man braucht nur den richtigen Key, der aber aus dem Master-Key und der Random UID berechnet wird.

Wegen mir schmeisse ich meine drei Karten auch weg und kaufe neue -- das ist mir diese Fortbildung wert!

ZitatÜbrigens ist die Akzeptanz von NFC bei der Family nicht überragend, nun kommt zusätzlich ein Zahlenschloss vor die Tür :-)
Link

ZitatSchade, warum denn nicht?

Verwöhnte Family ;-) Bei mir ist noch 90% FS20. Damals gab es die FS20-Keymatic mit Funk-Zahlenschloss (KeyMatic CAC). So sind die Kids ohne Schlüssel etc. aufgewachsen. Jetzt bin ich auf die HM-Keymatic gewechselt, die von FHEM aus gesteuert werden kann, aber eben kein HM-Zahlenschloss mehr hat.

ZitatP.S.: Trage übrigens seit fast 10 Jahren eine Junghans-Uhr mit integriertem Mifare-Chip. Habe jetzt mal die Schlüssel geknackt und kann den Chip endlich mal verwenden...

Ich glaube, du kannst hier noch einiges beitragen :-)

Hallo Welt!

Für meinen hochbetagten Vater, der jetzt alleine wohnt, baue ich gerade an einer Senioren-Sicherheitsvariante von FHEM. Kopfzerbrechen bereitet mir dabei immernoch der "Anwesenheitsstatus". Ein Mobiltelefon nutzt mein Vater nicht. Da wäre ein passiver RFID/NFC-Chip ideal. Kann man der Fritzbox das (NFC-)Kartenlesen nicht beibringen? Ich möchte eigentlich auch nicht noch einen extra Rechner dafür anstellen.

Vielen Dank auch mal an die Vordenker!

Christfried

Grüße aus Berlin

Zitat von: opa007 schrieb am Mi, 10 April 2013 10:35Für meinen hochbetagten Vater, der jetzt alleine wohnt, baue ich gerade an einer Senioren-Sicherheitsvariante von FHEM. Kopfzerbrechen bereitet mir dabei immernoch der "Anwesenheitsstatus".

Das hört sich für mich nach Homematic-Bewegungsmelder an, zur Not in jeden Raum einen.

ZitatDa wäre ein passiver RFID/NFC-Chip ideal. Kann man der Fritzbox das (NFC-)Kartenlesen nicht beibringen? Ich möchte eigentlich auch nicht noch einen extra Rechner dafür anstellen.

So einen RFID/NFC-Chip muss man explizit auflegen, da geht nichts aus der Entfernung. Das halte für diesen Fall für unzuverlässig (vergessen von Auflegen + Logik für Verlassen der Wohnung).
NFC auf Fritzbox: wenn ich sehe wie schwer es offenbar war, FHEM mehr oder weniger gut auf die Fritzbox zu portieren, dann halte ich das Unterfangen das alles NFC-relevante auf der FB zu bauen, für aussichtslos und für vertane Zeit.
Eine Raspberry Pi ist ein 3W-Rechner, sehr einfach zu installieren und kann per z.B. WLAN vollkommen unabhängig vom Standort der FB in der Wohnung montiert werden.

Nee, das hört sich für mich nach Homematic-Bewegungsmeldern in der Wohnung an. Man könnte auch per Mail alarmieren, wenn in einer gewissen Zeit keine Bewegung mehr festgestellt wurde.

==> Bitte für solche Diskussionen einen anderen Thread aufmachen und nicht hier unter "NFC-Tags steuern FHEM"

Danke und Grüße,
Martin

Ja, an Bewegungsmelder bzw. IR-Sensoren habe ich auch schon gedacht. Aber die reagieren auch auf die Katze. Da wäre eine eindeutige Anwesenheitsindentifizierung schon besser.
Im professionellen Bereich werden  RFID/NFC-Chips in Armbändern bei dementen alten Menschen mit "weg-lauf-Tendenzen" schon eingesetzt. Die Lösen einen Alarm aus wenn der Betreffende durch die Tür geht. Hat keiner eine Idee, wie die das machen?
Wenn Vater (bei Anwesenheit in der Wohnung) dann wieder nach einem Schlaganfall bewegungslos (Bewegungsmelder!) in der Wohnung liegt kann ich schneller reagieren


Wenn es eine andere, bessere Lösung für einen sicheren Anwesenheitsmelder gibt als RFID/NFC, ziehe ich mich auch demütig aus diesem Thread zurück... :-)


der Christfried aus Berlin

Hallo Christfried

Wenn es Dir wirklich um solch lebensbedrohliche Ereignisse wie einen Schlaganfall geht, dann würde ich niemals auf Selbstbaulösungen setzen. Es gibt Fallmelder, die per GSM sofort Alarm auslösen, wenn ältere Personen fallen (werden auch bei Arbeitern in gefährdeten Bereichen eingesetzt). Die arbeiten sicher und funktionieren überall, nicht nur in der Wohnung.

Wenn Du nur ein wenig mit der Technik experimentieren willst, dann muss ich Martin zustimmen: NFC heisst Near Field Communication und ist normalerweise nur für Distanzen zwischen 1 und max. 8cm ausgelegt. Um die Anwesenheit einer Person sicherzustellen, brauchst Du entweder 800MHz RFIDs (nur beschränkt sinnvoll, da Du für jeden Raum eine grosse Antenne bräuchtest) oder du machst es eben ganz anders (was ich empfehlen würde).

Eine Möglichkeit wäre mit Bluetooth zu arbeiten. Mit Bluetooth 4.0 (geringer Stromverbrauch) und Empfängern in jedem Raum kannst Du recht genau feststellen, ob die Person in der Wohnung ist. Oder, wenn Du Bewegungsmelder hast und einen Türkontakt, kannst Du mit etwas Logik auch berechnen, ob die Person die Wohnung verlassen hat oder nicht.

Viele Grüsse

Michael

Hallo Martin,

das mit dem Fallmelder schaue ich mir mal genau an. Gute Idee!
Mit der Bastellösung hast Du natürlich recht.

Danke!

Christfried

Moin,

Zitat von: Neuer_User schrieb am Do, 07 März 2013 16:29Ich kriege es aber nicht richtig hin. Habe jetzt einige Stunden probiert, "mifare-desfire-format" so zu ändern, dass es den Key richtig berechnet. Kriege aber keine Authentification hin. Kann mir jemand auf die Sprünge helfen, wo mein Fehler liegt? (Datei ist attached).

Zwei Probleme: A) Der Rückgabewert von freefare_get_tag_uid() ist aus Gründen die sich der Welt wohl auf immer verschliessen werden ein ASCII-Strings mit der eigentlichen UID in Hex (also "0473..." statt "\x04\x73..." etc. Alle meine Operationen erwarten eine Octet-Folge mit Längenangabe. B) freefare_get_tag_uid() ist die zufällige UID, nicht die feste. Zur Ableitung des Masterschlüssels habe ich (mehr aus Gewohnheit als aus anderen Gründen) die Original-UID verwendet. Die findest du in der log-Datei des card producers.

Zitat von: Neuer_User schrieb am Do, 07 März 2013 16:29Übrigens scheint es mir so, dass Henryks code keine Karten mit Random UID akzeptiert. Weiss jemand, warum das so ist? Sollte doch eigentlich kein Hindernisgrund sein, oder? Das würde ja bedeuten, dass man eine Karte, nachdem man sie einmal mit openkey benutzt hat und dann wieder neuformattiert hat, nicht mehr benutzen kann.

Ja, das ist so. Siehe oben. Der Grund für die UID ist, dass ich einen eindeutigen String brauchte für die Schlüsselableitung und die UID bequem verfügbar war und die Anforderungen erfüllte. Im Prinzip[tm] kann man auch hier eine UUID nehmen, muss sie nur, wie jetzt auch schon die UID, irgendwo speichern, falls man den PICC-Masterschlüssel nochmal braucht. (Die UID hat den Vorteil, dass man sie von der Karte abfragen kann, wenn man mindestens einen Schlüssel kennt.) Mir erschien der use case aber bisher noch nicht besonders plausibel, um das wirklich einzubauen. Da ich mir ohnehin grade Gedanken über Interoperabilität über Anwendungsgrenzen hinweg mache (arbeite noch an einer Bezahllösung), könnte das evt. noch kommen.

Zitat von: Neuer_User schrieb am Do, 07 März 2013 16:29Übrigens habe ich immer noch ein paar Probleme mit dem openkey-authenticator. Die LED auf dem Lesegerät flackert die ganze Zeit und eine Kartenidentifikation kann zwischen 1 und 10 Sekunden dauern oder auch gar nicht klappen. Zwischendurch schmiert das ACR122u dann noch ab und ist erst nach ausstecken/einstecken wieder erreichbar. Also noch nicht so ganz einsatzfähig. :-(

Probier mal, ob das besser geworden ist. Ich hab das auch beobachtet und erst in anderem Kontext wirklich einordnen können: libfreefare trackt den Kartenzustand nicht (wie ich das bisher von PC/SC gewöhnt bin) und gibt auch keinen Zugriff auf Fehlermeldungen von der darunterliegenden libnfc. Wenn eine Karte entfernt wurde, und man aber noch Kommandos absetzt (in dem Fall hier das Selektieren von anderen Slot-AIDs), dann werden die wirklich auf dem Funkinterface gesendet und Kontrolle kehrt erst nach dem Timeout zurück. Ich hab dagegen jetzt einen bösen Hack in den Code integriert der das Verhalten bei mir wesentlich verbessert, so sehr dass ich keine Timing-Probleme mehr sehe.

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

Moin,

Zitat von: opa007 schrieb am Do, 11 April 2013 07:36Im professionellen Bereich werden  RFID/NFC-Chips in Armbändern bei dementen alten Menschen mit "weg-lauf-Tendenzen" schon eingesetzt. Die Lösen einen Alarm aus wenn der Betreffende durch die Tür geht. Hat keiner eine Idee, wie die das machen?

"RFID" ist ein breites Feld und umfasst alles was irgendwie "Funk" und "Identifikation" enthält, von Freund/Feind-Erkennung in Kampfflugzeugen bis Diebstahlsicherung im Supermarkt. Anwendungen auf 13.56MHz sind nur ein kleiner Teil davon, und ISO 14443 (bzw. neuerdings NFC oder ISO 18092) ist nur ein kleiner Teil *davon*. ISO 14443 ist spezifiziert auf bis zu 10cm (real in der Regel unter 7cm). ISO 15693, ebenfalls auf 13.56MHz, ist immerhin schon auf bis zu 1m spezifiziert, für eine Tür-Anwendung durchaus akzeptabel. Noch andere (teilweise nicht standardisierte) Systeme auf teilweise noch anderen Frequenzen können noch größere Reichweiten haben. Speziell Backscatter-Systeme im UHF- oder Mikrowellenbereich können auch in die hunderte Meter Reichweite gehen. Und das sind nur die passive Systeme. Wenn du etwas Aktives mit Batterie verwenden kannst (ein Freund von hier hat dafür http://www.openbeacon.org/ entwickelt, im Einsatz unter anderem in Museen), kannst du noch viel freier sein und mehr damit machen.

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

Hi Hendryk

Zunächst einmal Danke für die Antwort.

Bezüglich des Formattierens werde ich das mal versuchen in nächster Zeit umzusetzen. Diese Woche wird das aber leider nichts.

Bezüglich der Probleme hat sich mit der neuen Version leider nichts bei mir geändert: Die LED flackert immer noch wie ein Stroboskob, Die Identifizierung von Karten scheint entweder in 1-2 Sekunden zu gehen oder gar nicht (bis 30 Sekunden probiert). Nach längerem Geflackere (mehrere Minuten) steigt der Treiber aus und ich muss den Leser abziehen und neu anstecken.

Folgende Fehlermeldungen sehe ich:

Auf der Console, sobald der Reader aussteigt:
error libnfc.driver.acr122_usb Unable to claim USB interface (No such device)
error libnfc.driver.acr122_usb Unable to claim USB interface (Bad file descriptor)
error libnfc.driver.acr122_usb Unable to claim USB interface (Bad file descriptor)

Im Syslog, sobald openkey-authenticator läuft:
Jun  4 08:04:43 DesktopMB kernel: [  885.428389] usb 5-1.4: reset full-speed USB device number 4 using xhci_hcd
Jun  4 08:04:43 DesktopMB kernel: [  885.449011] xhci_hcd 0000:03:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88021e0279c0
Jun  4 08:04:43 DesktopMB kernel: [  885.449016] xhci_hcd 0000:03:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88021e027a00
Jun  4 08:04:43 DesktopMB kernel: [  885.449018] xhci_hcd 0000:03:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88021e027a40
Jun  4 08:04:44 DesktopMB kernel: [  885.812305] usb 5-1.4: reset full-speed USB device number 4 using xhci_hcd
Jun  4 08:04:44 DesktopMB kernel: [  885.833054] xhci_hcd 0000:03:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88021e0279c0
Jun  4 08:04:44 DesktopMB kernel: [  885.833059] xhci_hcd 0000:03:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88021e027a00
Jun  4 08:04:44 DesktopMB kernel: [  885.833062] xhci_hcd 0000:03:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88021e027a40
Jun  4 08:04:44 DesktopMB kernel: [  886.196222] usb 5-1.4: reset full-speed USB device number 4 using xhci_hcd
Jun  4 08:04:44 DesktopMB kernel: [  886.216976] xhci_hcd 0000:03:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88021
[...]
Jun  4 08:09:32 DesktopMB kernel: [ 1174.057884] usb 5-1.4: Not enough bandwidth for new device state.
Jun  4 08:09:32 DesktopMB kernel: [ 1174.057892] usb 5-1.4: Busted HC?  Not enough HCD resources for old configuration.
Jun  4 08:09:32 DesktopMB kernel: [ 1174.058855] usb 5-1.4: USB disconnect, device number 4
Jun  4 08:09:32 DesktopMB kernel: [ 1174.058945] xhci_hcd 0000:03:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88021e0279c0


Kann das was damit zu tun haben, dass ich USB 3.0 auf dem Rechner habe? Ich habe bemerkt, dass die Benutzung von proxmark3 auf dem Rechner zu Totalfreezes in allen verfügbaren Kernels führt (Bug siehe hier: https://bugzilla.kernel.org/show_bug.cgi?id=55761 (//bugzilla.kernel.org/show_bug.cgi?id=55761)). Vielleicht ist das mit dem openkey-authenticator ja auch eine XHCI Sache? Werde das ganze mal auf einem USB2 System checken.

Was mir noch nicht klar ist, warum die LED die ganze Zeit blinkt. Es sieht so aus, als ob der Reader die ganze Zeit versucht, die Karte zu lesen, auch wenn gar keine aufgelegt ist. Sehr seltsam...

Ansonsten finde ich die Idee, mal eine wirklich recht sichere Authentifizierungslösung zu haben, genial. Vielen Dank also nochmal für Deine Mühen.

Michael

Zitat von: henryk schrieb am Mo, 03 Juni 2013 11:27Zwei Probleme: A) Der Rückgabewert von freefare_get_tag_uid() ist aus Gründen die sich der Welt wohl auf immer verschliessen werden ein ASCII-Strings mit der eigentlichen UID in Hex (also "0473..." statt "\x04\x73..." etc. Alle meine Operationen erwarten eine Octet-Folge mit Längenangabe. B) freefare_get_tag_uid() ist die zufällige UID, nicht die feste. Zur Ableitung des Masterschlüssels habe ich (mehr aus Gewohnheit als aus anderen Gründen) die Original-UID verwendet. Die findest du in der log-Datei des card producers.

Bezüglich B war das klar. Hatte die UID auch schon gefunden in dem log und verwendet (manuelle Eingabe in mifare-desfire-format). Problem A dürfte aber zum Scheitern geführt haben.

Verstehe ich das richtig, dass Du also für eine UID "045B3CF2541F80" den folgenden String genommen hast: "\x07\x04\x53...\x80" ?

Zitat

Zitat von: Neuer_User schrieb am Do, 07 März 2013 16:29Übrigens scheint es mir so, dass Henryks code keine Karten mit Random UID akzeptiert. Weiss jemand, warum das so ist? Sollte doch eigentlich kein Hindernisgrund sein, oder? Das würde ja bedeuten, dass man eine Karte, nachdem man sie einmal mit openkey benutzt hat und dann wieder neuformattiert hat, nicht mehr benutzen kann.

Ja, das ist so. Siehe oben. Der Grund für die UID ist, dass ich einen eindeutigen String brauchte für die Schlüsselableitung und die UID bequem verfügbar war und die Anforderungen erfüllte. Im Prinzip[tm] kann man auch hier eine UUID nehmen, muss sie nur, wie jetzt auch schon die UID, irgendwo speichern, falls man den PICC-Masterschlüssel nochmal braucht. (Die UID hat den Vorteil, dass man sie von der Karte abfragen kann, wenn man mindestens einen Schlüssel kennt.) Mir erschien der use case aber bisher noch nicht besonders plausibel, um das wirklich einzubauen. Da ich mir ohnehin grade Gedanken über Interoperabilität über Anwendungsgrenzen hinweg mache (arbeite noch an einer Bezahllösung), könnte das evt. noch kommen.

O.K. Verständlich. Es wäre aber schön, wenn man die UID dann vielleicht irgendwie eingeben könnte. Zwar könnte man die Karte mit einem modifiziertem mifare-desfire-format löschen (wenn ich das hinkriege), aber die Random UID lässt sich doch, glaube ich, nicht wieder abschalten, richtig?

Moin,

Zitat von: Neuer_User schrieb am Di, 04 Juni 2013 08:25Hi Hendryk

(6 Buchstaben, keiner davon ist ein 'd', 'c' oder 'i'. SCNR:)

Zitat von: Neuer_User schrieb am Di, 04 Juni 2013 08:25Auf der Console, sobald der Reader aussteigt:

Code Auswählen Erweitern

error libnfc.driver.acr122_usb Unable to claim USB interface (No such device)
error libnfc.driver.acr122_usb Unable to claim USB interface (Bad file descriptor)
error libnfc.driver.acr122_usb Unable to claim USB interface (Bad file descriptor)

Ok, du hast irgendein USB-Problem, dagegen kann ich in der library nicht viel tun. Ich hab versucht, bei mir was ähnliches durch Abziehen des Readers zu erreichen, da geht aber alles glatt. Je nach Phase in der ich abziehe kriege ich ein

error libnfc.driver.acr122_pcsc No ACR122 firmware received, Error: 80100016

aber nach dranstecken geht es immer wieder.

Hmm, ich sehe grade, dass du acr122_usb benutzt. Vielleicht muss ich den auch mal probieren.

Zitat von: Neuer_User schrieb am Di, 04 Juni 2013 08:25Kann das was damit zu tun haben, dass ich USB 3.0 auf dem Rechner habe? Ich habe bemerkt, dass die Benutzung von proxmark3 auf dem Rechner zu Totalfreezes in allen verfügbaren Kernels führt (Bug siehe hier: https://bugzilla.kernel.org/show_bug.cgi?id=55761). Vielleicht ist das mit dem openkey-authenticator ja auch eine XHCI Sache? Werde das ganze mal auf einem USB2 System checken.

Ohje, immer dieser neumodische Kram. Kannst du nicht den xhci-Treiber entladen und stattdessen ehci laden? Vielleicht geht das besser.

Zitat von: Neuer_User schrieb am Di, 04 Juni 2013 08:25Was mir noch nicht klar ist, warum die LED die ganze Zeit blinkt. Es sieht so aus, als ob der Reader die ganze Zeit versucht, die Karte zu lesen, auch wenn gar keine aufgelegt ist. Sehr seltsam...

Das muss so (naja). Jedes Kommando an den NFC-Chip im Reader führt zu einem LED-Flackern. Um herauszufinden, ob eine Karte im Feld ist, muss man pollen -> dauernd Kommandos senden. Richtigere Reader pollen selbst und geben Benachrichtigungen, über zum Beispiel PC/SC. Das braucht dann aber wieder kein libnfc mehr und geht deswegen nicht mit libfreefare.

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

Zitat von: henryk schrieb am Di, 04 Juni 2013 12:50Moin,

Zitat von: Neuer_User schrieb am Di, 04 Juni 2013 08:25Hi Hendryk

(6 Buchstaben, keiner davon ist ein 'd', 'c' oder 'i'. SCNR:)

Ohh, war wohl noch etwas zu müde :-) Sorry.

ZitatOk, du hast irgendein USB-Problem, dagegen kann ich in der library nicht viel tun. Ich hab versucht, bei mir was ähnliches durch Abziehen des Readers zu erreichen, da geht aber alles glatt. Je nach Phase in der ich abziehe kriege ich ein

Code Auswählen Erweitern


error libnfc.driver.acr122_pcsc No ACR122 firmware received, Error: 80100016

aber nach dranstecken geht es immer wieder.

Jein. Wird sicherlich irgendwie mit dem USB zu tun haben. Habe ja auch bei dem proxmark3 die erwähnten Probleme (andere Leute übrigens auch). Aber ich habe bisher noch nie dieses Problem gesehen mit den standard NFC Befehlen und auch nicht bei MFOC.

ZitatHmm, ich sehe grade, dass du acr122_usb benutzt. Vielleicht muss ich den auch mal probieren.

Ja,gerne. Welchen reader benutzt Du denn?

ZitatOhje, immer dieser neumodische Kram. Kannst du nicht den xhci-Treiber entladen und stattdessen ehci laden? Vielleicht geht das besser.

Ja, ganz Deiner Meinung. Und Ubuntu kompiliert die Treiber leider fest in den Kernel. Also leider nichts mit entladen. :-( Hatte beim Proxmark3 auch schon damit gekämpft.

Zitat

Zitat von: Neuer_User schrieb am Di, 04 Juni 2013 08:25Was mir noch nicht klar ist, warum die LED die ganze Zeit blinkt. Es sieht so aus, als ob der Reader die ganze Zeit versucht, die Karte zu lesen, auch wenn gar keine aufgelegt ist. Sehr seltsam...

Das muss so (naja). Jedes Kommando an den NFC-Chip im Reader führt zu einem LED-Flackern. Um herauszufinden, ob eine Karte im Feld ist, muss man pollen -> dauernd Kommandos senden. Richtigere Reader pollen selbst und geben Benachrichtigungen, über zum Beispiel PC/SC. Das braucht dann aber wieder kein libnfc mehr und geht deswegen nicht mit libfreefare.

Aaach sooo. Hatte erwartet, dass es irgendwie ein aktives Signal vom Reader gäbe wie "Tag found" und "Tag lost". Wenn ich Dich richtig verstehe, ist das eine Limitierung von libnfc und nicht vom Reader, richtig?

Moin,

Zitat von: Neuer_User schrieb am Di, 04 Juni 2013 14:46Ja,gerne. Welchen reader benutzt Du denn?

Den Touchatag mit dem acr122_pcsc-Treiber in libnfc. Und hab jetzt mal probiert, den acr122_usb-Treiber zu benutzen, aber der geht gar nicht bei mir. "error   libnfc.driver.acr122_usb   Too small reply", gibt schon einen Bugreport dazu.

Zitat von: Neuer_User schrieb am Di, 04 Juni 2013 14:46Ja, ganz Deiner Meinung. Und Ubuntu kompiliert die Treiber leider fest in den Kernel. Also leider nichts mit entladen.

Oh, das ist neuerdings zum Glück kein Problem mehr, man kann Treiber von Devices entbinden und auch wieder ranbinden. Für meinen USB2-Hostanschluss etwa:


$ sudo su -
[sudo] password for henryk:
# cd /sys/module/ehci_hcd/drivers/pci\:ehci_hcd
# ls -l
total 0
lrwxrwxrwx 1 root root    0 Jun  4 18:54 0000:00:1a.0 -> ../../../../devices/pci0000:00/0000:00:1a.0
lrwxrwxrwx 1 root root    0 Jun  4 18:54 0000:00:1d.0 -> ../../../../devices/pci0000:00/0000:00:1d.0
--w------- 1 root root 4096 Jun  4 18:54 bind
lrwxrwxrwx 1 root root    0 Jun  4 18:54 module -> ../../../../module/ehci_hcd
--w------- 1 root root 4096 Jun  4 18:54 new_id
--w------- 1 root root 4096 Jun  4 18:54 remove_id
--w------- 1 root root 4096 Jun  4 18:54 uevent
--w------- 1 root root 4096 Jun  4 18:54 unbind
# echo 0000:00:1d.0 > unbind
# echo 0000:00:1d.0 > bind


Du würdest halt das echo > unbind beim xhci-Treiber machen und das echo > bind beim ehci-Treiber. Keine Gewähr, aber sollte funktionieren. (Obacht: Keyboard sollte nich an dem USB-Anschluss hängen :)

Zitat von: Neuer_User schrieb am Di, 04 Juni 2013 14:46Aaach sooo. Hatte erwartet, dass es irgendwie ein aktives Signal vom Reader gäbe wie "Tag found" und "Tag lost". Wenn ich Dich richtig verstehe, ist das eine Limitierung von libnfc und nicht vom Reader, richtig?

Nein. Der 'Reader' ist gar kein Reader, das ist ein IC von NXP der (mit einer umständlichen Huckepackschaltung) an einem USB-Anschluss hängt. Der macht nichts von sich aus, der kann nichts von sich aus. libnfc fragt, ob ein Tag im Feld ist, und kriegt eine Antwort, das muss man dann immer wieder machen.  (Genauer gesagt, kann der Chip doch ein Kommando der Art "Schaue nach Tags, und melde dich erst wieder, wenn du eins gefunden hast.", aber das geht mit der Huckepackschaltung nicht, die erwartet, dass auf alle Kommandos innerhalb einer recht kurzen Zeit eine Antwort kommt.)

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

Hallo zusammen,

versuche seit ein paar Tagen den Stick zu installieren... und komme jetzt leider nicht weiter.

habe alles erledigt wie in der WIKI beschriben

auf den Befehl:
root@raspberrypi:~# tail -f /var/log/messages

bekomme ich auch den Stick zu sehen:

ZitatAug 30 02:17:52 raspberrypi kernel: [    5.796158] NET: Registered protocol family 39
Aug 30 02:17:52 raspberrypi kernel: [    5.938880] pn533 1-1.4:1.0: NFC: NXP PN533 firmware ver 2.7 now attached
Aug 30 02:17:52 raspberrypi kernel: [    6.224039] usbcore: registered new interface driver pn533
Aug 30 02:17:52 raspberrypi kernel: [    6.624219] bcm2708-i2s bcm2708-i2s.0: Failed to create debugfs directory
Aug 30 02:17:52 raspberrypi kernel: [   11.574807] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
Aug 30 02:17:52 raspberrypi kernel: [   12.061436] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
Aug 30 02:17:52 raspberrypi kernel: [   17.747115] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Aug 30 02:17:52 raspberrypi kernel: [   20.134196] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Aug 30 02:17:52 raspberrypi kernel: [   21.722116] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
Aug 30 02:17:55 raspberrypi kernel: [   29.365319] Adding 102396k swap on /var/swap.  Priority:-1 extents:1 across:102396k SSFS
Aug 30 10:55:02 raspberrypi kernel: [  207.928601] usb 1-1.4: USB disconnect, device number 4
Aug 30 10:55:02 raspberrypi kernel: [  207.929151] pn533 1-1.4:1.0: NFC: NXP PN533 NFC device disconnected
Aug 30 10:55:08 raspberrypi kernel: [  214.051461] usb 1-1.4: new full-speed USB device number 5 using dwc_otg
Aug 30 10:55:09 raspberrypi kernel: [  214.223503] usb 1-1.4: New USB device found, idVendor=04e6, idProduct=5591
Aug 30 10:55:09 raspberrypi kernel: [  214.223539] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Aug 30 10:55:09 raspberrypi kernel: [  214.223556] usb 1-1.4: Product: SCL3711-NFC&RW
Aug 30 10:55:09 raspberrypi kernel: [  214.223569] usb 1-1.4: Manufacturer: SCM Micro
Aug 30 10:55:09 raspberrypi kernel: [  214.239972] pn533 1-1.4:1.0: NFC: NXP PN533 firmware ver 2.7 now attached

Leider geht es aber ab da nicht weiter:
nfc-list | grep "NFC device"

Ergebniss:

Zitatbash: nfc-list: command not found

Was ist schief gelaufen ?

Kann mir jemand helfen?

Der Befehl (genauer: das Programm) nfc-list ist auf Deinem System nicht vorhanden. Hast Du die nfc-Tools installiert?

apt-get install libnfc-bin

Also ganz so einfach war es dann nicht, aber ich habe es so weit geschafft  :P

Allerdings gibt mir der Befehl nfc-List erst mal kein Ergebnis bis ich nicht sudo modprobe -r pn533 noch eingebe.

Der  sudo /usr/local/bin/nfc2fhem.sh habe ich auch vorerst manuell gestartet, aber darüm später.

ich bekomme leider keine Reaktion aus FHEM.
Aber im Terminal sehen ich das die Tags erkannt werden.

Zitatpi@raspberrypi ~ $ sudo modprobe -r pn533
pi@raspberrypi ~ $ sudo nfc-list
nfc-list uses libnfc libnfc-1.7.1
NFC device: SCM Micro / SCL3711-NFC&RW opened
pi@raspberrypi ~ $ sudo /usr/local/bin/nfc2fhem.sh
Please define 0447aeba392b80 first
Please define 0447aeba392b80UIDNFCID1 first
Please define 0447aeba392b80UIDNFCID1 first
Please define 0447aeba392b80UIDNFCID1 first
Please define 0447aeba392b80UIDNFCID1 first
Please define 0447aeba392b80 first

Kann jetzt gerade nicht ganz nachvollziehen warum.

Jemand eine Idee?

interessant wäre zu wissen, was in /usr/local/bin/nfc2fhem.sh eigentlich drinsteht (was damit gemacht wird?)

Die Fehlermeldungen sagen doch eindeutig, was das Problem ist: Es wird versucht, zwei fhem-Devices anzusprechen, die nicht definiert sind.

Please define 0447aeba392b80 first
Please define 0447aeba392b80UIDNFCID1 first

Danke Danke, vielleicht sollte man den Tag Namen richtig schreiben :-) und ab und zu auch mal was anderes machen.

Hallo,

ich möchte Euch kurz an meinen Erfahrungen teilhaben lassen.

Erst einmal herzlichen Dank für den Wiki-Eintrag.

Ich habe mir das Modul von Elechouse gekauft: http://www.elechouse.com/elechouse/index.php?main_page=product_info&cPath=90_93&products_id=2242 . Angebunden ist es am RPi über UART. Es läuft übrigens einwandfrei mit einer VCC von 3.3V, so dass ohne weitere Klimmzüge das Modul mit vier Drähten angeschlossen werden kann.

Zur Installation habe ich die aktuelle libnfc 1.7.1 genommen und habe auch nur den Treiber für UART kompiliert.

Das Modul hat nach der Vorgehensweise im Wiki direkt funktioniert. Allerdings habe ich in anderer Sache auf einmal Probleme bekommen. Ich habe eine CCU mit einem CUL und einem HMLAN konfiguriert. Und irgendwie ging auf einmal alles nicht mehr so richtig, ständig hatte ich missing Acks. Eingrenzen konnte ich das merkwürdige Verhalten meiner Aktoren auf Vorhandensein seit der Installation von der libnfc bzw. dem Daemon, der ständig die NFC-Reader abfragt.

Lange Rede, kurzer Sinn: Unbedingt in der /etc/nfc/libnfc.conf den Wert allow_intrusive_scan=false setzen. Sonst kommt sich list-nfc mit CUL (USB) in die Quere und CUL steht auch nicht mehr auf "initialized" bzw. "ok" in der CCU sondern nur noch auf "opened".

Im nfc2fhem.sh habe ich noch wie folgt Änderungen vorgenommen:

    NFCID="$(nfc-list | grep NFCID -m 1)"
    [[ $NFCID != '' ]] &&
    {
        NFCID="$(echo $NFCID | cut -b 15- | sed 's/ //g;s/)//g;s/(//g' | tr -d ' ')"
        echo "set $NFCID read" | nc -w5 $FhemIP 7072
        echo "`date`: $NFCID detected" >>$LogFile
        sleep 4
    }

Damit wird immer nur maximal eine Ausgabe ausgewertet und ab dem 15. Byte alles als ID genommen. Aus dieser werden alle Leerzeichen verworfen.

Hallo erstmal

Ich habe mein Raspi mittels PN532 um NFC erweitert und habe mich an der WIKI orientiert (Danke dafür).
Nur die Poll-Zeit mittels nfc-list war mir etwas zu langsam und hab dafür eine Lösung gefunden.
Von NFC-Tools gibt es ein NFC-Event Daemon names nfc-eventd. Dieses kleine Tool kann den Tag wesentlich schneller einlesen.
Falls jemand Interesse hat, hier der Link....
http://nfc-tools.org/index.php?title=Nfc-eventd (http://nfc-tools.org/index.php?title=Nfc-eventd)

Das Startstript nfc2fhem hab ich als Basis genommen und lediglich die Binary angepasst und in der Konfig "/usr/local/etc/nfc-eventd.conf" habe ich folgendes noch unter "# Tag inserted" hinzugefügt.

Zitataction = "echo 'set $TAG_UID irgendwas' | nc -w5 127.0.0.1 7072";

Gruß
Rubinho

Leider läuft der Daemon nur nicht stabil. Nach ein paar wenigen Minuten mag er nicht mehr. Darüber hinaus scheint er auch den CUL an USB zu stören, obwohl der Daemon auf den NFC-Leser an ttyS2 festgedübelt ist.

Das ist blöd, dass es bei dir nicht stabil läuft.
Bei mir funktioniert der event daemon bis jetzt ohne jegliche Probleme.  Allerdings habe ich auch andere Vorraussetzung.
Mein PN532 ist via SPI an dem Raspi angebunden und verträgt sich wohl besser mit dem Daemon.

Hallo zusammen,

der Thread ist zwar ältern, aber ich hoffe dennoch auf Hilfe. Ich habe mit heute libopenkey auf meinem RPi installiert allerdings scheint irgendwas nicht zu funktionieren, denn ich bleibe schon beim Einrichten der DESfire hängen:

pi@raspberrypi ~ $ openkey-producer openkey_secrets_dir taki_card1
Note: Bootstrapping card producer role and generating secret keys
        This may take some time ...

Der Leser selber (ein I2C-Board von ELEHOUSE) funktioniert:

pi@raspberrypi ~/libnfc $ nfc-scan-device
nfc-scan-device uses libnfc libnfc-1.7.1-28-gef74d81
1 NFC device(s) found:
- pn532_i2c:/dev/i2c-1:
    pn532_i2c:/dev/i2c-1

Sowohl nfc-poll, als auch mifare-desfire-info scheinen auch zu funktionieren:

pi@raspberrypi ~/libnfc $ nfc-poll
nfc-poll uses libnfc libnfc-1.7.1-28-gef74d81
NFC reader: pn532_i2c:/dev/i2c-1 opened
NFC device will poll during 30000 ms (20 pollings of 300 ms for 5 modulations)
ISO/IEC 14443A (106 kbps) target:
    ATQA (SENS_RES): 03  44 
       UID (NFCID1): 04  88  33  d2  5e  2d  80 
      SAK (SEL_RES): 20 
                ATS: 75  77  81  02  80 
nfc_initiator_target_is_present: Target Released
Waiting for card removing...done.

pi@raspberrypi ~ $ mifare-desfire-info
===> Version information for tag 048833d25e2d80:
UID:                      0x048833d25e2d80
Batch number:             0xba4454d6d0
Production date:          week 15, 2013
Hardware Information:
    Vendor ID:            0x04
    Type:                 0x01
    Subtype:              0x01
    Version:              1.0
    Storage size:         0x18 (=4096 bytes)
    Protocol:             0x05
Software Information:
    Vendor ID:            0x04
    Type:                 0x01
    Subtype:              0x01
    Version:              1.4
    Storage size:         0x18 (=4096 bytes)
    Protocol:             0x05
Master Key settings (0x0f):
    0x08 configuration changeable;
    0x04 PICC Master Key not required for create / delete;
    0x02 Free directory list access without PICC Master Key;
    0x01 Allow changing the Master Key;
Master Key version: 0 (0x00)
Free memory: 4864 bytes
Use random UID: no

Hat jemand (Hendryk vielleicht?) einen Tipp, wie ich mit der Fehlersuche weitermachen kann?

Freundliche Grüße

Taki