Forum: Mikrocontroller und Digitale Elektronik Mifare DESFire EV1 - Lesegerät gesucht.


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von JumpY Μ. (jumpy)


Lesenswert?

Hallo,
ich bin auf der Suche nach einem bestimmten Lesegerät für Mifare DESFire 
EV1 Karten. Die Karten sind vorhanden und nur die UID soll gelesen 
werden. Mehr Informationen werden hier garnicht benötigt, da keine 
Sicherheitsbereiche damit aufgeschlossen werden und eine Manipulation 
ausgeschlossen wird.
Leider finde ich keine wirklich geeigneten Lesegeräte oder Module dafür, 
die das wirklich können. Bei dem RFID-RC522 steht DESFire z.B. auch 
angegeben, die Karten werden aber garnicht erst erkannt wenn die im Feld 
sind. (Davon habe ich etliche hier liegen, oder geht das vielleicht doch 
und ich habe nur absolut falschen Code oder sonstiges? Ich glaube 
eigentlich nichtmehr dran..)
Das Gerät kann gerne auch fertig mit USB Schnittstelle sein, es wird 
vermutlich direkt am Raspberry Pi angeschlossen, falls andere 
Kommunikation kann auch ein Arduino vorgeschaltet werden.

Hat da schon jemand Erfahrungen? Wie gesagt nur lesen der UID, nichts 
anderes und keine Schreibfunktionen werden benötigt. Dementsprechend ist 
eine günstige Lösung bevorzugt. (Und nach Möglichkeit hier bestellbar, 
nicht in China ;))

von Alex A. (alexdetsch)


Lesenswert?

Soweit ich weiß, senden die EV1 ihre UID nur ein einziges Mal, d.h. du 
weißt nicht, wie lange sie im Feld bleibt, wenn du nur die UID liest. 
Danach erst wieder wenn Du sie erneut ins Feld hälst.

Der PN532 von NXP dürfte die aber lesen können. Oder Du hast 
fehlerhaften Code, das dürfte auch nicht ganz unwahrscheinlich sein.

von JumpY Μ. (jumpy)


Lesenswert?

PN532 Habe ich keinen hier, nur RC522. Dieser wird auf allen Seiten auch 
mit DESFire beworben, im Netz habe ich noch niemanden gefunden, der das 
auch geschafft hat. (S50 Karten z.B. funktionieren ohne Probleme..)
Es ist nicht notwendig zu wissen wielange die Karte im Feld bleibt, 
damit soll man sich nur in einem System "einscannen", dafür muss die UID 
nur einmal gefangen werden.
Den PN532 habe ich bislang auch gesehen, ich wollte nur ungerne 40$ in 
China zahlen für ein Produkt, was dann wieder nicht funktioniert und 
deshalb erst hier nachhören. Vielleicht hat ja noch jemand etwas 
anderes, oder sofort ein "fertiges" USB-Gerät in einem solchen 
Preisbereich.

von Heizer (Gast)


Lesenswert?

Die UID einer EV1 geht auf jeden Fall mit dem RC522.
Bis dahin ist das eine ganz normale Iso14443A Karte.
Die UID ist bei denen die ich bisher in den Fingern hatte 7 Byte lang.

von JumpY Μ. (jumpy)


Lesenswert?

Aaaha, das hört sich doch interessant an. Ich dachte eben auch, dass es 
bis dahin total irrelevant ist, welcher Chip genutzt wird und nur die 
anderen Daten nicht auslesbar/veränderbar sind.
Du sprichst davon, dass du sowas scheinbar öfter gemacht hast, hast du 
dazu zufällig noch Code? Du kannst mich gerne auch per PN kontaktieren 
und da sagen wo wir sprechen sollen. Laut Datasheet ist die UID 7 bytes, 
das ist richtig, mit dem Read oder Dump Sketch die bei den normalen Libs 
dabei sind passiert aufjedenfall garnichts. Also keine Ausgabe, auch 
nicht, dass es eine falsche Karte oder ähnliches ist und im Netz finde 
ich leider auch nichts genaueres dazu wo sowas schonmal einer ans laufen 
bekommen hat...

von Andreas (Gast)


Lesenswert?

Ein fertiges RC522-Modul bekommt man z.B. über

http://www.amazon.de/Neuftech-IC-Card-RFID-Module/dp/B00QFDRPZY/ref=sr_1_1?ie=UTF8&qid=1445623487&sr=8-1&keywords=rc522

(1. Treffer bei der Suche).

Das Teil ist billig und lässt sich problemlos an einen Arduino und zur 
Not auch an einen Raspberry anschließen.
Zusätzlich bietet NXP auf deren Website auch das Datenblatt und etliche 
Application Notes zu diesem Chip an mit denen man schnell was anfangen 
kann.
Früher hat NXP auch eine Reader-Library angeboten - weiß allerdings 
nicht mehr, ob es die noch gibt.

Der RC522 unterstüzt den ISO 14443 (A) Standard und kann damit nicht nur 
DESFire- sondern auch Mifare- und viele andere -Karten lesen.
Da du nur die UID lesen willst, sollte das völlig ausreichend sein.

Wenn man sich ein wenig mit Kryptographie beschäftigt kann man mit dem 
RC522 ebenfalls die gesamten Funktionen einer DESFire Karte nutzen 
(siehe Datenblatt des DESFires).

Falls es noch mehr Fragen gibt, einfach bescheid sagen..

lg.
Andi

von JumpY Μ. (jumpy)


Lesenswert?

Diese Module habe ich zu etlichen hier liegen, S50 Auslesung z.B. 
funktioniert ohne Probleme schon seit längerem. Nun ist ja z.B. der 
Unterschied, dass die Mifare DESFire EV1 Karte eine 7byte UID hat, die 
anderen nur 4byte.
Verwendet habe ich zahlreiche verschiedene Librarys dazu, z.B. die von 
Miguel Balboa, allerdings bei den Desfire's alle ohne Erfolg. Ich bin 
doch nicht der 1. Mensch, der dazu Google bemüht, es gibt aber nirgends 
bislang einen Lösungsansatz oder eine Library dazu.

Wie gesagt, bislang stehe ich auf dem Punkt, dass meine 4byte Karten 
funktionieren, die 7byte aber nicht. Sobald ich die Karte in den Leser 
halte passiert nichts, keinerlei Reaktion.

von Heizer (Gast)


Lesenswert?

Zu den Libs die im Umlauf sind kann ich nichts sagen. Ich habe das in C 
auf einem Pic selber geschrieben.
Bei NXP auf der Seite findet man Beispielcode für die Rc522 und Rc523.
Ist zwar für ein 8031 Derivat, kann man aber als Basis gut verwenden

von JumpY Μ. (jumpy)


Lesenswert?

Ich habe die MFRC522 Seite von NXP jetzt schon 5x durchsucht und noch 
immer keinen Hinweis auf Beispiele gefunden, lediglich die ausführliche 
Dokumentation, welche leider meinen Wissensstand überschreitet.

Ich hätte dir gerne ein PN oder Mail geschrieben, damit das hier nicht 
so hin und her ohne wirklichen Wissensstand ist, du bist aber leider als 
Gast hier unterwegs.
Wenn du damit einverstanden bist, schreibe mir bitte kurz eine Mail an 
JumpY2k3@gmx.net.

Danke dir

von Alex A. (alexdetsch)


Lesenswert?

Ich benutze den PN532, da ich später noch die P2P-Funktion brauche, die 
der RC522 nicht hat. Auf jeden Fall funktioniert da das auslesen der 
UIDs auch von den DESFires (Studentenausweis, nPA). (Wie kommst Du 
eigentlich darauf, das Modul mit dem PN532 würde 40€ kosten? Ich habe 
16€ bezahlt...)

Hier sagt jemand, dass es mit dem RC522 nicht geht: 
http://arduino.stackexchange.com/questions/1329/how-do-i-use-rfid-rc522-with-an-arduino
https://regnerischernachmittag.wordpress.com/2013/08/03/5euro-rfidnfc-modul-rc522-zum-auslesen-von-mifare-tags/

Wofür brauchst Du eigentlich in Deiner Umgebung die DESFire-Karten?

von JumpY Μ. (jumpy)


Lesenswert?

Ich habe mir eben auch ein PN532 Board gekauft, hat ~23€ gekostet. 
(Hatte zunächst das Seeedstudio im Auge, das war für 40 zu haben..)
Die beiden Seiten habe ich natürlich schon gesehen, ebenfalls wie ca. 10 
andere Seiten die sagen, dass es nicht funktioniert. Die arbeiten 
allerdings alle mit den Libs die so im Netz zu finden sind, damit 
funktioniert es ja nicht, habe ich ja auch festgestellt.

Ich kann zwar dann das PN532 Board nutzen, wenn das bei mir 
funktioniert, wäre aber trotzdem fein, wenn man wüsste wie es mit den 
RC522 funktioniert.(Davon habe ich immerhin 10 Stück hier liegen..)

Die Mifare DESFire EV1 Karten liegen mir für mein Projekt vor, heißt ich 
muss diese nutzen. Das sind eigentlich Karten mit Zutrittsberechtigung 
in verschiedene Bereiche, dass soll nur ein kleines seperates System 
sein, wo man sich mit der Karte "einbuchen" kann. Wie bereits erwähnt 
spielt dabei Sicherheit keine Rolle, es muss dementsprechend nur die UID 
erkannt werden.

von Andreas (Gast)


Lesenswert?

OK - nur damit ich es auch richtig verstehe - du kannst die 4-Byte UID 
einer Mifare-Karte (z.B. S50) lesen, nicht aber die 7-Byte UID einer 
DESFire Karte, korrekt ?

In dem Fall würde ein schneller Blick in
o) den ISO 14443-Standard
o) den NFC-Standard (z.B. ECMA 340)
o) die vielen Application Notes von NXP zum Thema Kartenaktivierung 
("PICC
   Selection")
o) das DESFire Datenblatt selbst
helfen.

Kurze Zusammenfassung:
======================
1. Reader sendet "Request-A" (0x26)
2. Karte antwortet mit ATQA (2 Byte)
3. Reader sendet "AntiCollision" (0x93 0x20)
4. Karte antwortet mit 4-Byte UID + BCC ( = XOR über die 4-Byte UID)
5. Reader sendet "Select" (0x93 0x70 + UID + BCC)
6. Karte antwortet mit SAK (1 Byte, 1 Bit darin bestimmt ob die UID
   komplett ist, was bei deiner DESFire Karte dann entsprechend gesetzt
   ist; glaube es ist invertierte Logik "UID not Complete")
7. Wenn die UID nicht komplett ist, schickt der Reader ein weiteres
   AntiColiision mit 0x95 0x20 danach gehts bei Schritt 4 weiter (Select
   dann auch mit 0x95 0x70 ..).
8. Solltest du mal eine Karte mit 10-Byte haben, schickst du für
   AntiCollision 0x97 0x20.

Der ganze Prozess wird komplizierter wenn sich mehr als 1 Karte im Feld 
befindet, aber ich denke dass das bei deiner Anwendung nicht der Fall 
ist.
Ansonsten kann ich hier gerne helfen.

Für den DESFire muss also irgendwo in deiner verwendeten Library eine 
AntiCollision-Sequenz, d.h. irgendwas mit 0x93 0x20, geben.
Wenn es sich nur auf diese Sequenz beschränkt, kann die Library auch nur 
4-Byte UIDs lesen. Aber das sollte sich dann problemlos erweitern lassen 
(eben AntiCollision Level 2 mit 0x95 0x20).

Ein paar Application Notes für den Beginn:
o) AN10834 MIFARE ISO/IEC 14443 PICC Selection
o) AN10927 MIFARE and handling of UIDs
o) AN10833 MIFARE Type Identification Procedure
Sind alle von NXP.

lg.
Andi

von JumpY Μ. (jumpy)


Lesenswert?

Ja, hast du komplett richtig verstanden.
Deine Erläuterung dazu ließt sich zumindest schonmal seh gut, ich hoffe 
dazu Informationen finden zu können die ich auch umsetzten kann. (Werde 
das hoffentlich heute in Angriff nehmen können)

Falls du dich weiter dafür interessierst, bei mir wird z.B. aktuell 
folgende Library verwendet. Darin steht auch etwas zu 4,7,10 bytes UID, 
das habe ich schon gelesen, die Anwendung aber nicht richtig verstanden. 
(Warscheinlich wegen fehlendem Hintergrundwissen)
Zu finden ist das in der MFRC522.cpp ab Zeile 574.
Lib: https://github.com/miguelbalboa/rfid

Nochmals kurz zur Info: Es passiert rein garnichts! Es ist also nicht 
so, dass die ersten 4 Bytes ankommen oder ein Lesefehler oder sonstiges 
angezeigt wird. Es passiert absolut garnichts, wenn man die Karte in den 
Lesebereich hält. (Deswegen weiß ich auch nicht 100%ig, ob der Code 
überhaupt dafür ausgelegt ist, oder ob es ganz anderen Code oder eine 
andere Lib benötigt)

Gruß

von Rena Z. (rena2019)


Lesenswert?

@jumpy: als ich den oben verlinkten Blogartikel geschrieben hatte (vor 2 
Jahren?) war der RC522 Code nur für 4Byte UID ausgelegt. In meinem 
Github Repository hatte ich dann den erweiterten (7Byte UID) Code 
eingecheckt. Wie ich mich dran erinnern kann konnte waren die 
aufgelisteten NFC Tags/Karten Gar nicht dazu bewegen von dem RC522 
erkannt zu werden, als wenn sie nicht ins Feld gehalten werden.
Entweder ist die Antenne schlecht kalibriert/designt/ausgelegt oder der 
DESFire hat noch irgendwelche Restriktionen????
An dem RC522 Code  Methodenaufruf  Parametern konnte man glaub ich 
nichts weiter ändern.....ich schaue aber heute Abend evtl nochmal drauf 
und gebe Feedback.
Klar mit dem PN532 hat man mehr Freiheiten, ist die bessere Wahl

von Andreas (Gast)


Lesenswert?

Rena Z. schrieb:
> Entweder ist die Antenne schlecht kalibriert/designt/ausgelegt oder der
> DESFire hat noch irgendwelche Restriktionen????

Weder noch, die Kartenaktivierung (=Auslesen der UID + Auswählen) beim 
DESFire funktioniert wie bei jeder anderen ISO 14443(A) kompatiblen 
Karte auch. Der DESFire spezifische Teil beginnt erst wenn man das T=CL 
(= ISO 14443-4) Protokoll aktiviert. Und selbst dann kann damit noch 
arbeiten.

Die Antenne ist auch in Ordnung, denn sonst könnte ja die 4-Byte UID 
einer Mifare-Karte auch nicht gelesen werden.

lg.

von JumpY Μ. (jumpy)


Lesenswert?

Ich habe gerade nochmal nachgsehen, die Karten und Schlüsselanhänger des 
Typs "MIFARE Classic (MF1S50)" werden mit dem RC522 Modul und der Lib 
von miguelbalboa ohne Probleme gelesen. Die andere Karte wie bereits 
erwähnt nicht.

Ich habe mir die Dateien dazu mal angesehen, muss aber feststellen, dass 
mir das eine Nummer zu tief in die ganze Sache eingreift als das ich 
daran selber etwas ändern könnte.
Die Kollisionswerte 93/95/97 sind in der MFRC522.h enthalten. Die 
Library prüft meiner Meinung nach schon die UID Längen und wertet dann 
entsprechend aus. (An mehreren Stellen ist dort etwas von 4byte, 7byte 
und 10byte zu sehen)

Hier hört mein Wissensstand darüber nun leider auf. Ich kann nicht 
feststellen, ob es jetzt doch "nur" eine Codefrage ist, oder ob die 
Hardware da doch eine gewisse Rolle spielt. Gibt es eine 
Prüfmöglichkeit, ob die Karte überhaupt durch den Leser erfasst wird?

Ich wäre nach wie vor sehr daran interessiert, die UID irgendwie 
auslesen zu können. Falls sich jemand dazu bereiterklärt den Code 
nachzuvollziehen oder sogar einen Code dazu hat, wäre ich diesem sehr 
dankbar. (Heizer hat das ja weiter oben schonmal angesprochen, dass er 
sowas gehabt hat, vielleicht existiert das ja noch und er würde es zur 
Verfügung stellen, wenn er sich dann nochmal meldet.)

Mich wundert es allerdings noch immer, dass niemand diese Idee bereits 
aufgefasst hatte oder daran etwas gearbeitet hat. (Zumindest das, was 
man auf Github dazu findet)
Die Entwickler der normalen Librarys sind ja vermutlich ziemlich Fit in 
dem Umgang damit gewesen, da kann ich es mir leider nicht richtig 
vorstellen, dass diese nicht weiter daran gearbeitet hätten oder nie auf 
die Idee der DESFire Auslesung gekommen sind.

Gruß
JumpY

EDIT: In der Datei MFRC522.h stehen im Header übrigens verschiedenste 
Kartentypen aufgelistet, wo DESFire nicht aufgeführt wird. Dafür ist 
Beispielsweise der Typ "MIFARE Ultralight" aufgeführt und dieser nutzt 
ebenfalls eine 7-byte UID. Somit müsste das ja eigentlich möglich sein, 
wenn die Karte dann erkannt wird im Feld?

: Bearbeitet durch User
von Andreas (Gast)


Lesenswert?

Simon W. schrieb:
> Gibt es eine
> Prüfmöglichkeit, ob die Karte überhaupt durch den Leser erfasst wird?

Ja, in der verlinkten Library gibt es in der Datei MFRC522.cpp in Zeile 
480 die Methode "PICC_RequestA". Wenn du diese in deinem Code ausführst 
und von der DESFire-Karte 2 Byte empfängst (= ATQA), dann weißt du, dass 
sowohl dein Leser als auch deine Karte prinzipiell funktioneren.

Achtung: Das Kommando funktioniert nur jedes 2. Mal, da die Karte nach 
einem erfolgreichen Request-A den internen State wechselt. Ich kann hier 
nur nochmal auf einen kurzen Blick in die ISO 14443 hinweisen...

von JumpY Μ. (jumpy)


Lesenswert?

Ich habe das jetzt mal versucht, allerdings ohne Erfolg. Ich wusste 
nicht 100%ig wie ich die Funktion da richtig aufrufen kann, deswegen 
habe ich in der Funktion "PICC_IsNewCardPresent()" ein 
"Serial.println(bufferATQA[2]);" eingebaut. Damit sehe ich bei den S50 
Tags eine Veränderung der Ausgabe wenn ich die in Reichweite halte, bei 
den DESFire-Karten aber nicht.
Leider bin ich in C relativ unbeholfen, besonders wenn es so umfangreich 
ist.

Vielleicht findet ja jemand er anderen die noch daran arbeiten möchten 
etwas, ansonsten muss ich da wohl eher passen. Und ja, der Hinweis mit 
der ISO 14443 ist schön und gut, wenn man den Code der hier verwendet 
wird nicht nachvollziehen kann, ist das leider schlecht anwendbar.

von Andreas (Gast)


Lesenswert?

Simon W. schrieb:
> Damit sehe ich bei den S50
> Tags eine Veränderung der Ausgabe wenn ich die in Reichweite halte, bei
> den DESFire-Karten aber nicht.

Wenn beim Senden eines Requests bei Mifare eine Änderung der Ausgabe 
erhältst, bei den DESFire-karten aber nicht sieht das nach defekten 
Karten aus.
Das ist sehr ungewöhnlich, kann aber vorkommen.

Hast du irgendwie die Möglichkeit zu prüfen, ob das wirklich 
DESFire-Karten sind ? Oder handelt es sich dabei um irgendwelche 
unbeschrifteten Karten und / oder z.B. Schlüsselanhänger.

Simon W. schrieb:
> Und ja, der Hinweis mit
> der ISO 14443 ist schön und gut, wenn man den Code der hier verwendet
> wird nicht nachvollziehen kann, ist das leider schlecht anwendbar.

Sorry wenn ich immer wieder auf den Standard / die Spezifikation 
verweise - es ist nicht meine Absicht hier irgendwie zu nerven. Es soll 
nur ein nützlicher Hinweis sein.
Aber in dem Dokument sind einfache Ablaufdiagramme enthalten, welche die 
Kartenaktivierung ohne viel Text sehr gut beschreiben - und gerade wenn 
man in dem Umfeld - wie du selbst sagst - nicht viel Erfahrung hat, ist 
das meiner Meinung nach unerlässlich um überhaupt zu verstehen, was der 
Code macht.

Ich habe mir den Code angesehen und abgesehen, dass der Author nicht 
alle HW-Features des Chips verwendet sondern viel manuell macht (z.B. 
automatische Berechnung + Senden der CRC_A Checksumme), sieht das alles 
korrekt aus.

Daher mein Verdacht, dass die Karten entweder defekt (unwahrscheinlich) 
sind oder dass es sich dabei nicht wirklich um DESFire-Karten sondern um 
Karten handelt, die nicht zu ISO 14443-A kompatibel sind.

Andere Frage noch - hast du oder jemand in deinem Umfeld zufällig ein 
Smartphone welches NFC unterstützt ?
Falls ja, gibt genug freie Apps zum Auslesen von Karten - damit könnte 
man
ebenfalls noch prüfen was es für ein Kartentyp ist und / oder ob die 
Karten defekt sind.
Je nach verbautem NFC-Chip unterstützt dieser auch Standards neben der 
ISO 14443-A. Ein Versuch wäre es Wert.

von JumpY Μ. (jumpy)


Lesenswert?

Irgendwo hatte ich weiter oben erwähnt, dass ich überhaupt nur durch das 
Smartphone weiß, dass dies Mifare DESFire EV1 Karten sind. Unten in den 
Links ist ersichtlich, welche Daten mir die App auf meinem Handy dazu 
ausgibt. Die Karte Funktioniert zu 100%, hätte sogar noch eine DESFire 
EV1 Karte hier, die aus einer anderen Charge kommt. (Mensakarte der FH)

Gewünschte Karte: http://pastebin.com/W6sXT6Gk
Mensakarte: http://pastebin.com/UzRuvMJJ

Ich habe da gewisse Stellen durch XXX unkenntlich gemacht, weil ich 
nicht genau wusste durch welche Informationen auf die UID etc. schließen 
kann. Überall wo ein X ist, war also vorher eine Zahl/Buchstabe.

Was mir auffällt, die Mensakarte ist zwar auch eine DESFire EV1 Karte, 
allerdings mit 4-byte UID. Diese lässt sich allerdings auch nicht 
auslesen (zumindest nicht ohne Veränderung des Codes). Warscheinlich 
existiert keine richtige Routine für die DESFire Karten in der Lib?

Frage: Wärest du vielleicht bereit, mir einen Arduinosketch zu senden, 
wie du meinst, dass ich eine Änderung feststellen müsste? Ich weiß jetzt 
nicht genau ob da ein Sketch ausreicht, oder ob du etwas an der Lib 
ändern musst, falls ja diese dann auch. Natürlich nur wenn du dazu Lust 
und vorallem Zeit hast, so könnte ich zumindest prüfen, ob der Leser 
irgend eine Reaktion wahrnimmt... Ich denke für erfahrene Nutzer bzw. 
C-Könner ist das dann doch mehr oder weniger einfach, weiß es aber eben 
nicht.

EDIT: Bei der Mensakarte ist das glaube ich ein Anzeigefehler. Die Karte 
wird zwar in der NXP-eigenen App als DESFire angezeigt, in anderen Apps 
aber als unbekannt. (Die gewünschte Karte ist überall DESFire!!)
Die Mensakarte wechselt nach jedem Lesevorgang die UID, anders als die 
gewünscht Karte, die behält ihre UID schön bei.

: Bearbeitet durch User
von Rena Z. (rena2019)


Lesenswert?

Aus gegebenem Anlass habe ich nochmal meine Kartensammlung durchprobiert 
und auch den Blogartikel 
https://regnerischernachmittag.wordpress.com/2013/08/03/5euro-rfidnfc-modul-rc522-zum-auslesen-von-mifare-tags/ 
aktualisiert

Folgende Karten reagieren nicht mal auf ein PICC_REQIDL = 0x26 (bzw 
kehrt der entsprechende Request-Aufruf nicht zurück):

* Mifare Ultralight C (MF0ICU2), 7byte-UID
* Mifare Classic 1K 'MF1 IC S5009' alias Mifare Plus S (MF1SPLUS60)
* Mifare DESFire EV1 (MF3ICD21) HW v1.0
* Mifare DESFire (MF3ICD40) HW v0.2
* Mifare DESFire EV1 (MF3ICD81) HW v1.0
* Mifare Classic 1K (emulated)

Bei folgenden Tags konnte zumindest die UID gelesen

* Mifare Classic
* Mifare Classic (MF1S70)
* NTAG203 (NT2H0301)
* NTAG215 (NT2H1511) alias amiibo cards
* NTAG216 (NT2H1611G0DUx)
* Mifare Classic Futan FM11RF08
* Mifare Classic Clonable China Card
* Miafre Ultralight (MF0ICU1) alias GVB card
* Infineon ??? Chip alias Geldkarte

von JumpY Μ. (jumpy)


Lesenswert?

Rena hat hier ja super Arbeit geleistet, habe auch nochmal ausführlicher 
mit ihm gesprochen. Wir haben verschiedenste Librarys auf Arduino und 
Raspberry Pi getestet, alle ohne Erfolg. Auch die Befehle innerhalb der 
Library die unterscheiden ob eine Karte im Feld gefunden wurde oder 
nicht geben auch keinen Erfolg.
Jetzt kann es eigentlich nur 2 Möglichkeiten geben: Entweder der gesamte 
Vorgang wie die Libs aufgebaut sind funktionieren nicht und da sind 
irgendwelche Register falsch gesetzt, welche wir aber nicht finden, oder 
es ist mit den fertigen Modulen einfach nicht möglich.

Ich würde mich weiterhin sehr darüber freuen, wenn die 2 Personen die 
hier scheinbar Erfahrung damit haben sich mit mir kurzschließen würden 
und mir dazu etwas sagen könnten. Ich denke mal, dass zumindest der Code 
für die Erkennung der Karte (ohne Auslesen) nicht sonderlich aufwendig 
wäre und würde mich freuen wenn diese Personen mir soetwas zeigen 
könnten. "Heizer" vom Beginn des Threads hat sowas ja sogar schon fertig 
umgesetzt, mit ein bisschen Glück schaut er nochmal hier rein und kann 
seinen Code zeigen oder erinnert sich zumindest noch daran was er 
gemacht hat. Ansonsten sehe ich leider nicht mehr viele Chancen das zum 
Laufen zu bekommen.

von Axel (Gast)


Lesenswert?

Hallo,

ich habe exakt die gleichen Erfahrungen mit dem RC522 und der Desfire 
EV1 gemacht. Mifare Classic Karten funktionieren problemlos, Desfire 
Karten werden nicht mal erkannt. Ich wäre auch sehr an einer 
funktionierenden Lösung mit dem RC522 interessiert und biete gerne 
Unterstützung beim testen an.

Gruß

Axel

von JumpY Μ. (jumpy)


Lesenswert?

Das scheint es leider hier gewesen zu sein. Ich habe keine weitere Idee 
mehr und alle Tests die ich umsetzen konnte sind abgschlossen.
Vielleicht meldet sich irgendwann ja nochmal jemand, schade.

von Axel B. (abarkow)


Lesenswert?

Ich habe mir gestern noch einmal etwas genauer mit dem RC522 beschäftigt 
und mal mit dem Oszi gemessen, was zwischen PCD und PICC wirklich 
passiert. Dort sind definitiv Unterschiede zwischen einer Desfire und 
einer Classic Karte zu sehen, die Desfire scheint gar nicht zu 
antworten. Ein schneller Vergleich mit einem PN532 zeigt, dass das 
Kommando vom PCD gleich aussieht.
Leider hatte ich gestern nur Zugriff auf das "kleine" Oszi, sobald ich 
das größere zur Verfügung habe, werde ich ein paar Bilder online 
stellen.
Was mir auch aufgefallen ist, dass die gemessenen Spannungspegel an der 
Antenne bzw. mit einer Schnüffelspule am PN532 Breakout Board deutlich 
größer sind als am RC522. Vielleicht genügt die Feldstärke nicht für die 
Desfire? Habt ihr mal versucht, mit den Parametern des MFRC522 zu 
experimentieren, die die Antennentreiber und Empfangsteile beeinflussen 
(RFCfgReg, GsNReg, CWGsPReg, ModGsPReg, ...)?
Ich habe leider erst kommende Woche wieder Zugriff auf die Hardware, 
werde mir das Thema aber noch weiter anschauen.

Gruß

Axel

von JumpY Μ. (jumpy)


Lesenswert?

Das klingt durchaus interessant. Meine Vermutung war es ebenfalls, dass 
es nicht am Chip, sondern an der Verarbeitung der Platine/der 
Ansteuerung liegt. Die Antenne und alles sonstige ist evtl. durch den 
Code anders abgestimmt und es gibt deshalb Probleme, ebenfalls könnte 
die Feldstärke tatsächlich zu klein sein.
Mit den Einstellungen selber habe ich noch nichts gemacht, da ich keine 
passende Hardware habe um Signale zu verfolgen. Mit einem Oszi und der 
nötigen Erfahrung kann man aber bestimmt an den Werten schrauben und 
vielleicht eine Veränderung sehen, würde mich sehr freuen wenn du dazu 
nochmal berichtest.

Ich habe mitlerweile auch ein PN532 Board erhalten, bis auf einen 
kleinen Kommunikationsfehler in der Software funktionierte das Teil auf 
Anhieb innerhalb 5 Minuten. Alle vorhandenen Karten können gelesen 
werden, gibt also keine Probleme. (Also meine Karten scheinen alle i.O. 
zu sein ;))

von Rena Z. (rena2019)


Lesenswert?

@Axel: Prima, das ist genau das was ich auch beobachtet habe: der 
DESFire antwortet nicht auf das REQA.
Das Feld für den DESFire muss stärker sein da DESFire 
uController-basiert ist und mehr Leistung als der Mifare Classic 
ASCI-basierte Chip benötigt.

Rumgespielt hatte ich bis jetzt aber nur mit dem RFCfgReg Register für 
die RxGain, wobei der maximale Wert von 48 dB keine Unterschiede 
gebracht hatte. Ich werde mir die anderen Register nochmal anschauen.

von Rena Z. (rena2019)


Lesenswert?

Bei einer MF3ICD40 Mifare DESFire Karte bekomme ich nun ab und zu (zu 3% 
= scheint sehr instabil zu sein bzw die Registerwerte scheinen noch 
nicht alle zur Antenne zu passen?) eine Antwort auf mein REQA!

von JumpY Μ. (jumpy)


Lesenswert?

Ach du meine Güte, das gibt's ja garnicht! :)

Info: Das PN532 Board wird ja im Vergleich zum R522 über 5V gespeist. 
Ich habe mein RC522 mal ausversehen per 5V gespeist, habs zumindest 
damit nicht zerstört, ich weiß allerdings nicht welches das 
Spannungsbegrenzende Bauteil auf der Platine ist. (Also das Teil welches 
nur 3.3V darf)
Ist ja eigentlich auch mehr oder weniger logisch, dass bei 5V ein 
größeres Feld aufgebaut werden könnte, oder irre ich micht da?
Es wäre natürlich genial, wenn du mit der Einstellung alleine da etwas 
bewirken könntest, vielleicht braucht die Antenne aber auch einfach mehr 
Saft, aber der Chip ist auf 3.3V ausgelegt?

von Rena Z. (rena2019)


Lesenswert?

@ Simon: so einfach ist das nicht. Im RC522 Datenblatt 
http://www.nxp.com/documents/data_sheet/MFRC522.pdf steht supply 
voltage: 3.3V, max: 3.6V -> freu Dich wenn Du den Chip damit nicht 
gebraten hast.
PN532 http://www.adafruit.com/datasheets/pn532ds.pdf VBAT darf 5V sein, 
weil er intern noch einen Regulator hat.
Mehr ist nicht immer besser ;-)

von Axel B. (abarkow)


Lesenswert?

@Rena
Sehr schön. Welche Registerwerte hast du jetzt angepasst? GsNReg und 
CWGsPReg, so dass maximale Power ausgegeben wird (ist das eigentlich 0 
oder F?) und RFCfgReg auf maximale Verstärkung?

Ich wollte mir auch noch mal den Aufbau der Antenne anschauen. Hat 
jemand zufällig einen Schaltplan? Ich hatte gestern den Schaltplan der 
Antenne teilweise erstellt, um mir den Antennenaufbau genauer anschauen 
zu können. Dabei ist mir aufgefallen, dass dieser zu keiner der in den 
Appnotes genannten Vorschläge passt. Vielleicht ist auch nur die 
Abstimmung der Antenne schlecht. Ich wollte zu Testzwecken den MFRC522 
mal an den Antennenaufbau eines PN532 hängen und schauen, ob das etwas 
verbessert.
Beim Aufbau meiner eigenen Platine (allerdings mit PN532) habe ich schon 
die Erfahrung gemacht, dass die Antennenabstimmung durch sehr diffizil 
ist. Leider stehen mir aber nicht alle in der Appnote genannten 
Werkzeuge zur Verfügung.

Gruß

Axel

von Rena Z. (rena2019)


Lesenswert?

@Axel: Registerwerte habe ich jetzt nach diversem Rumspielen eigentlich 
gar nicht geändert nur die Antenne (4 Wicklungen Lackdraht an das Board 
gelötet 
https://regnerischernachmittag.files.wordpress.com/2015/11/rc522_my_antenna.jpg). 
Damit kann man dann bei Millimetergenauer Ausrichtung die DESFire Karten 
ansprechen.

: Bearbeitet durch User
von Axel B. (abarkow)


Lesenswert?

Ich habe heute noch mal mit den Registerwerten experimentiert. Mit 
GsNReg und CWGsPReg kann ich durchaus das Feld beeinflussen, das lässt 
sich auch gut im Oszi beobachten. Nur reicht ein volles aufdrehen nicht, 
um die Desfire Karten lesen zu können.
Ich werde mir in den nächsten Tagen mal die Antenne vornehmen und 
mittels der Appnote versuchen, diese abzustimmen.

Gruß

Axel

von Rena Z. (rena2019)


Lesenswert?

@Axel: was ändert sich denn am Feld, wenn Du an den angegebenen 
Registerwerten drehst?

von Axel B. (abarkow)


Lesenswert?

Ich messe mit ein paar Windungen Draht am Tastkopf des Oszi zwischen 
RC522 und RFID Karte. Wenn ich die Registerwerte Richtung Null ändere, 
wird die induzierte Spannung kleiner, wenn ich sie erhöhe größer. 
Gegenüber dem Resetwert kann ich die Spannung noch um ein paar mV 
erhöhen, reicht aber scheinbar nicht.

Gruß

Axel

von Axel B. (abarkow)


Lesenswert?

Kennst du eigentlich die folgenden Seiten:

https://www.mikroe.com/forum/viewtopic.php?f=147&t=64203
https://revspace.nl/RC522Hacking

In beiden Fällen schient eine Fehlanpassung der Bauteile die Ursache der 
Probleme zu sein. Ich habe heute auch mal versucht, einen Schaltplan zu 
zeichnen. Im Netz findet sich bspw. folgender 
http://www.elecrow.com/download/MFRC522_ANT.pdf
Der kommt dem von mir ermittelten schon recht nahe, die Bauteile der 
Antenne sind auf jeden Fall so angeordnet, wie ich es ermittelt habe. 
Was die Bauteilgrößen insbesondere der Kondensatoren angeht, kann ich 
noch nicht sagen, ob die Werte so korrekt sind.
Gegenüber der NXP Appnote 
(http://www.nxp.com/documents/application_note/AN1445_An1444.zip) ist 
vor allem der Empfangsteil anders. Auch die Bauteilwahl (zumindest wie 
im Schaltplan angegeben) kann ich anhand der Appnote noch nicht 
nachvollziehen.

Gruß

Axel

von Rena Z. (rena2019)


Lesenswert?

Netter Fund! Kannte ich noch nicht. Dann mal angestellt den 
SMD-Backofen...

von Axel B. (abarkow)


Lesenswert?

Juhu, es läuft. Ich habe zunächst wie in [1] beschrieben, die 
Kondensatoren getauscht. Auf meiner Platine sind das C10 und C11. Diese 
haben ursprünglich einen gemessenen Wert von 280pF (kommt unter 
Berücksichtung der Toleranz den 220pF recht nahe) und ich habe sie durch 
100pF ersetzt. Dies hat jedoch die Situation nicht verbessert.
Dann habe ich mich an den Tausch der Induktivitäten L1 und L2 gemacht, 
wie in [2] beschrieben. Mangels Auswahl habe ich folgende neue 
Induktivitäten verwendet: [3]. Mit dieser Konfiguration bekomme ich 
endlich eine Antwort der Defire Karte auf den REQA. Ich habe die 
Kondensatoren auch wieder durch die Originale ersetzt, so dass der 
Tausch der Induktivitäten die einzige notwendige Änderung ist. Ich würde 
nun mal schauen, welche passenden und beschaffbaren Induktivitäten denn 
eingesetzt werden könnten.
Als nächstes würde ich schauen, ob ich die weiterführende Kommunikation 
mit der Desfire Karte lauffähig bekomme. Hier sehe ich aber gute 
Chancen, ohne weitere Probleme ans Ziel zu kommen.

Gruß

Axel


[1]: https://revspace.nl/RC522Hacking
[2]: https://www.mikroe.com/forum/viewtopic.php?f=147&t=64203
[3]: http://katalog.we-online.de/pbs/datasheet/744032002.pdf

von JumpY Μ. (jumpy)


Lesenswert?

Hallo Axel,
ich habe deinen Beitrag zwar sofort gelesen, hatte aber bislang relativ 
wenig Zeit mir darüber Gedanken zu machen. Freut mich sehr, dass es bei 
dir zu einem gewissen Erfolg gekommen ist, hast du daran schon weiter 
gemacht? Mir würde die Bestimmung der UID z.B. ja ausreichen, weitere 
Fälle würden auch deutlich mehr Aufwand mit sich bringen.
Was aber wichtig wäre: Hast du nochmal die Standardkarten versucht? Es 
wäre ja schon wichtig, dass diese weiterhin wie gewohnt funktionieren. 
(Dann könnte man ein kleines Kombisystem daraus machen)

Gruß
Simon

von Axel B. (abarkow)


Lesenswert?

Hallo Simon,

ja, ich habe weiter gemacht. Ich habe das Modul an einem Beaglebone 
Black betrieben und konnte mit Hilfe der Bibliothek von Miguel Balboa 
[1] auch direkt auf die Desfire Karten zugreifen (lediglich bzgl. der 
SPI Anbindung musste ich kleinere Änderungen vorsehen) und die UID 
auslesen. Ich habe bislang nicht getestet, ob die Classic Karten 
weiterhin funktionieren, kann mir aber keinen Grund vorstellen, was das 
verhindern sollte.
Auf Basis der Bibliothek habe ich einige weitere Desfire Funktionen 
implementiert (SelectApplication, Authenticate, GetValue, Debit, 
ReadData - alle auf Basis von AES), mit deren Hilfe ich auf von mir mit 
anderer Hardware formatierte Karten erfolgreich zugreifen kann. Aktuell 
versuche ich mich mit einer Portierung auf einen STM32, meinem 
eigentlichen Zielprozessor.

Gruß

Axel

[1]: https://github.com/miguelbalboa/rfid

von JumpY Μ. (jumpy)


Lesenswert?

Klasse, das hört sich doch sehr gut an. Dann müsste ich das wohl auch 
mal in Angriff nehmen und testen, dann könnte ich mein Projekt um 
Mifare's erweitern, und noch ein anderes Projekt angehen.
Wenn du da irgendwann etwas ansehnliches fertig hast, wäre es 
interessant den Code davon zu sehen. (Die Bib von Balboa kenne ich, die 
nutze ich auf dem PI aktuell ebenfalls ohne Probleme mit den 
Standardkarten)

von Axel B. (abarkow)


Lesenswert?

Du findest den aktuellen Stand hier: 
https://github.com/barkow/stm32-rfid.git

Gruß

Axel

von Stanislav (Gast)


Lesenswert?

Tut mir bitte leicht fur mein Deutsch.
Du kanst benutzt mfrc522 und Desfire EV1 einwnderfrei, mit 
des/2k3des/aes.
Die 3DES - 120ms Authorisierung process mit dem Atmega329p
Und mit AES128 - 5-10ms.
Ich habe kaine library dieses Zeit, aber du kanst mir fragen shtelle 
uber algorithm und theorie.
Ich habe viele log's auf einem russishe forum geshriebt, und immer noch 
weitere logirung.
http://radiokot.ru/forum/viewtopic.php?f=2&t=145789&sid=e9fb435e01cc1dd63b4a1f37274286b4&start=80

von Rena Z. (rena2019)


Lesenswert?

@Stanislav: Hast Du denn ein fertiges Board gekauft oder die 
Induktivitäten L1 und L2 (wie in "MFRC522 from Ebay - tips how to get 
more RF power" https://forum.mikroe.com/viewtopic.php?f=147&t=64203 
beschrieben) ausgetauscht?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.