Hallo, gestern kam endlich mein Nexus 5, leider musste ich jedoch feststellen das es keine Mifare Classic mehr lesen kann :/ Dummerweise habe ich hier einige hunderte Tags in allen Varianten und etliche "Arduino"-Reader/Writer hier :( Was könnt ihr als Alternative empfehlen? Die alternativen Tags sollten später auch mit einem Atmega ausgelesen werden können. Leider findet man im Internet recht wenig bzw. nur etwas zu den Mifare Classic Karten, die ich jetzt leider nicht mehr brauchen kann... Hat einer von euch Erfahrungen mit Alternativen? Viele Grüße Julian
Julian W. schrieb: > Was könnt ihr als Alternative empfehlen? Die alternativen Tags sollten > später auch mit einem Atmega ausgelesen werden können. Für wieviel würdest du es verkaufen wollen? Gruß
al3ko schrieb: > Für wieviel würdest du es verkaufen wollen? Was verkaufen!? Das Nexus 5? Das will ich nicht verkaufen :D Ich will lieber neue NFC-Tags haben die mit dem Handy funktionieren und die auch noch ein Atmega in den Griff bekommt.
Mein Nexus 5 liest Mifare Classic 1K ganz ausgezeichnet.
Whaa! Ist NFC nicht ein STANDARD!?!?!? Dann warte ich doch lieber noch mit dem Smartphone-Upgrade, da ich keine Lust habe alle meine Tags zu ersetzen. Muss man tatsächlich für jedes Smartphone bzw. jedes HW-Refresh einen neuen Satz an Tags anschaffen? Das kann doch nicht im Sinne des Erfinders sein... (Wie ist das z.B. mit den NFC Bezahlsystemen?)
Boris B. schrieb: > Whaa! Ist NFC nicht ein STANDARD!?!?!? Mifare Classic ist NICHT Nfc. Mifare Classic folgt schon dem ISO 14443-A nicht. Schau dir mal die 18000er Standards an. > Dann warte ich doch lieber noch mit dem Smartphone-Upgrade, da ich keine > Lust habe alle meine Tags zu ersetzen. Muss man tatsächlich für jedes > Smartphone bzw. jedes HW-Refresh einen neuen Satz an Tags anschaffen? > Das kann doch nicht im Sinne des Erfinders sein... Mifare Classics sind um es sanft zu sagen nicht mehr das Wahre. Um es hart zu sagen: für die Tonne. - Sie folgen dem Standard nicht. - Sie haben sehr beschränkten Speicher - Ihre Verschlüsselung ist auf mehrere Weisen geknackt > (Wie ist das z.B. mit den NFC Bezahlsystemen?) Basiert nciht auf einem Kartentyp. Je nach dem welches über klassisches ISO 7816-4 + EMV Apps, NDEF Messages oder eigenes ...
Maxx schrieb: > Mifare Classic ist NICHT Nfc. > Mifare Classic folgt schon dem ISO 14443-A nicht. Das scheint wohl das Problem zu sein, wobei ich bei den ganzen Standards nicht mehr durchblicke... von Milfare gibt es ja etliche Typen keine Ahnung was jetzt was unterstützt und wofür ist... :( Kennt jemand von euch eine RFID-Karte die den NFC Stsndard unterstützt und auch ohne viel Aufwand von einem Atmega angesteuert werden kann? "Sicherheit" spielt eigentlich keine Rolle daher gingen bisher auch die Mifare Classic...
Quark! NFC = Near Field Communication (AFAI ... ohne zu googeln weiß) Diese Nahfeldkopplung kann über viele verschiedene Standards erfolgen. Insofern ist der Begriff bei den Smartphones etwas "unglücklich" gewählt. Die gängigsten Standards sind entweder auf 125kHz und 13,56Mhz unterwegs. Während man beim 125kHz Standard DIREKTEN Kontakt braucht, können die 13,56MHz bis zu 10cm überbrücken. Ist bei Bezahlkarten und Reisepässen zwar nicht ideal, aber wer weiß warum man den gewählt hat ... Eben bei den 13,56 MHz gibt es die beiden A/B Varianten des ISO/IEC Standards 14443. Meines Wissens unterscheiden die sich nur in der Codierung. Mifare = ISO 14443-A !!! Waren lange Zeit die einzigen die da rumgefunkt haben. Daher haben die sich auch als Quasistandard eingeschlichen. Stichwort E-Reisepass, diverse Mensa-Karten, Zugangskontrolle usw ... das NFC-Forum versucht jetzt das Chaos mit den Standards etwas einzudämmen. Soviel ich weiß ist NXP (Philips) mit seinem Mifare Zeugs quasi federführend. Brauchst du wirklich die Classic 1k ??? Aber hoffentlich nicht wegen der "Sicherheitsfeatures" die schon lange jedes Skriptkiddie knacken kann ;-)
Kalle schrieb: > Brauchst du wirklich die Classic 1k ??? Aber hoffentlich nicht wegen der > "Sicherheitsfeatures" die schon lange jedes Skriptkiddie knacken kann > ;-) Ne ich brauch nur irgendwelche NFC/RFID-Karten die ein paar Bytes Speicher haben. Sicherheit spielt bei mir eigentlich keine Rolle, schadet aber bestimmt nicht falls man das mal aufrüsten will in Richtung Türöffner oder ähnliches. Kalle schrieb: > Kennste? > http://www.nfc-tag.de/kompatibilitaetsliste Danke, eine hilfreiche Seite für mich war dann noch: http://www.nfc-tag-shop.de/info/ueber-nfc-tags/nfc-tag-typen.html Also gibt es die NFC Typen 1-4, wobei diese sich wohl nur in Speicher/Kapazität unterscheiden? Wie funktioniert das nun mit der Sicherheit? Verwenden alle das gleiche Protokoll? Also funktionieren z.B. Mifare Ultralight, Milfare DESFire und NTAG 203 alle mit dem gleichen "NFC-IC"? Weil einmal liest man was von 3DES Verschlüsslung, AES Verschlüsslung oder gar keiner Verschlüsslung!? Nur wie kommuniziere ich mit diesen Chips über einen einfachen 8-bitter wie den Atmega? Dazu fand ich bisher leider fast gar nichts brauchbares :(
Puuuh, ui ... muss zugeben, dass ich da dann doch etwas mehr getan hat als ich erwartet habe. Habe vor ca. 4-5 Jahren zuletzt mit gearbeitet. Das war zu der Zeit als Mifare gerade geknackt wurde. Mein Ziel war das selberaufladen meiner Mensa-Karte ;-) Also der Typ scheint wohl die Angehängte Zahl zwischen Standard und Typ A/B zu sein. Das Problem scheint wohl zu sein, dass Nexus 5 und Galaxy S4 (meins) auf den einen NFC-IC von Broadcom setzen. Nexus 7 und Galaxy S3 haben noch einen von NXP und daher keinerlei Probleme mit den Classic 1k von NXP. Das Crypto-1 Zeugs ist wohl nicht zu machen von Broadcom. Selbst als Anwender hab ich damals diverse NDAs unterschreiben müssen :-/ Mein Tipp wäre wenn Sicherheit keine Rolle spielt und du nur ein paar Bytes speichern möchtest: Mifare Ultralight ... die gehen eigentlich immer. Für Sicherheitskritische Sachen würde ich jetzt wohl auf "Ultralight C" setzen oder DESfire setzen. Wo hast du AES gelesen? Ich hab damals als 8-Bitter nen PIC18F4620 genommen. Der hat dann seriell per SPI mit dem MFRC531 gesprochen. Den Mifare "Stack" mit dem CCS Compiler. Daher ist das heutzutage quasi nicht mehr zu gebrauchen ;-)
Wozu kann man NFC hierzulande eigentlich nutzbringen einsetzen? Ich habe zwar ein Handy damit, aber mir erscheint das bisher überwiegend als eine Lösung auf der Suche nach dem passenden Problem.
Kalle schrieb: > Wo hast du AES gelesen? im Wiki Artikel von Mifare werden z.B. die "MIFARE Plus S", "MIFARE Plus X" und "MIFARE DESFire EV1" mit AES-128 Verschlüsslung angegeben. Bei einem 8bitter ist sowas in Software zu implementieren nicht gerade ne gute Lösung... Kalle schrieb: > Ich hab damals als 8-Bitter nen PIC18F4620 genommen. Der hat dann > seriell per SPI mit dem MFRC531 gesprochen. Den Mifare "Stack" mit dem > CCS Compiler. Daher ist das heutzutage quasi nicht mehr zu gebrauchen > ;-) Weiß einer was heute zu gebrauchen ist? :D
hä? Mein Code ist nicht mehr zu gebrauchen weil er mit dem Pseudo ANSI-C Compiler gecodet wurde. Wie willst du das denn sonst implementieren? In Hardware per VHDL und tausenden Zustandsautomaten? :-/ Du muss sogar zwischen Ultralight und Classic unterscheiden. Also um low-level Firmware wirst du nicht drumrum kommen. Es sei denn du kaufst dir so einen Hobby-Reader der seinerseits mit dem NFC-IC kommuniziert. Also wenn ichs noch richtig weiß frägt man eh erstmal nach dem Unique Identifier. Dann macht man das Anti-Collisioning falls mehrere Karten in Lesereichweite sind. Anschließend wird der Kartentyp abgefragt und dadurch das entsprechende Protokoll definiert. Ab dann wird in der Sprache des Kartentyps gesprochen. Für die Classic musst du schließlich z.B. auch einen Key-A und Key-B zum sichern diverser Datenbereiche schicken. Eine Ultralight Karte würde hier nur Bahnhof verstehen. Mein Tipp wäre: Leg dich auf einen Kartentyp und maximal eine Karte in Reichweite fest. Am einfachsten ists mit der Ultralight Karte. btw: Einsetzen kann man diese Karten für diverse proprietäre Anwendungen. Aber standardisiert ist noch kaum etwas. Die Sparkassen fangen wohl derzeit mit ihrem Girogogo Mist an. Zumindest hab ich in den DM-Dogerien schon diverse Reader gesehen. In Zukunft kann man beispielsweise mit der EC-Karte Beträge bis 20 EUR bezahlen. Mit dem Handy kannste dann per App gucken was noch drauf ist :D Aber genaues weiß ich auch nicht. Ultralight war damals übrigens auch das WM-Ticket 2006.
Kalle schrieb: > Du muss sogar zwischen Ultralight und Classic unterscheiden. Also um > low-level Firmware wirst du nicht drumrum kommen. Es sei denn du kaufst > dir so einen Hobby-Reader der seinerseits mit dem NFC-IC kommuniziert. Okay klingt etwas komplizierter. Bisher hatte ich nur Classic Karten, da gab es für den Arduino schöne Shields und eine LIB mit der das Ansteuern eigentlich super simpel war, aber diese Karten möchte ich nicht mehr verwenden. Die Ultralight C wären dann wohl der nächst "einfache, sichere" Karten-Typ. Die DESFire haben eine Dateisystem ähnliche Struktur was es sicher nicht einfacher macht... Wo fange ich da jetzt am besten an bzw. welcher IC kann man empfehlen, der noch recht einfach anzusteuern ist? Fertige Shields konnte ich keine finden bzw nur für die Ultralight ohne C:( Kurz zum Vorhaben: Wir haben einen Party-Keller und zwecks Abrechnung wollten wir das mit RFID-Karten machen. Von daher wäre es toll wenn die "Kasse" die Schulden des Gastes auf die Karte schreibt und man später mit dem Handy selbst seine Karte nur auslesen kann (A und B Keys bei Mifare Classic). Das ganze soll später noch wachsen über Türöffnung, PC Authentifizierung (zur Musik Steuerung) etc.
http://www.nxp.com/documents/application_note/AN10833.pdf Hier ists schön erklärt wie es läuft. Jede Karte kann ihr eigenes Protokoll haben. Nur die Kommunikation auf unterstem Layer ist definiert. Alles andere musst du dann in Software umsetzen.
Julian W. schrieb: > im Wiki Artikel von Mifare werden z.B. die "MIFARE Plus S", "MIFARE Plus > X" und "MIFARE DESFire EV1" mit AES-128 Verschlüsslung angegeben. > > Bei einem 8bitter ist sowas in Software zu implementieren nicht gerade > ne gute Lösung... Das mit der Verschlüsselung bezieht sich nur auf die Funkstrecke zwischen Karte und RFID Controller. Wenn der RFID Controller das beherrscht, sendet der uC nur paar Kommandos und um den Rest kümmert sich der RFID Controller. Prinzipiell macht es aber natürlich schon Sinn, dann auch die weitere Strecke zwischen RFID Controller und uC zu verschlüsseln.
Also für die Anwendung würde ich auch auf ein fertiges Shield setzen. Mit ner entsprechenden Library dürfte das gar kein Problem sein. Mit dem Arduino Zeugs kenn ich mich leider gar nicht aus. ... Naja will es eigentlich auch nicht ;-) Der Aufwand wäre mir zu hoch für nen Partykeller. Hab jetzt spontan aber auch kein Shield gefunden, welches die Protokollbehandlung der Karten abfängt bzw. ich weiß nicht ob es für den Arduino fertigen Code gibt. Sorry, da muss ich passen.
PS: Ob der Reader Chip von NXP ist oder nicht ist erstmal wurscht und daran kann man nicht festmachen ob ein Chip Mifare tauglich ist. Mit nem Legic Controller kann ich auch Mifare Karten lesen und das hat nix mit NXP zu tun.
> Prinzipiell macht es aber natürlich schon Sinn, dann auch die weitere > Strecke zwischen RFID Controller und uC zu verschlüsseln. nee nee ... wieso? Meinst, dass da jemand am SPI rumschnüffelt? :D Also das Problem wirst du immer haben zumal ists unwahrscheinlich. Verschlüsselt ist wirklich nur das was durch die Luft geht. Mit dem Reader IC rede ich Klartexr.
A. B. schrieb: > PS: Ob der Reader Chip von NXP ist oder nicht ist erstmal wurscht > und > daran kann man nicht festmachen ob ein Chip Mifare tauglich ist. > > Mit nem Legic Controller kann ich auch Mifare Karten lesen und das hat > nix mit NXP zu tun. Jou, nur andersrum wird ein Schuh draus. NXP-Controller können ALLE Mifare. Da Mifare auf dem Mist von Philips/NXP gewachsen ist. Jedoch können die anderen AUCH Mifare, da das ja ansich nicht schwierig ist so lange alles offengelegt ist. Das gilt auch für öffentliche Krypto-Standards wie DES, Triple-DES, AES usw ... aber NICHT für den proprietären Crypto-1 den damals NXP mit seinen Mifare Classic 1k zusammengeschustert hat. Der ist nämlich nicht öffentlich bekannt und daher kann den Broadcom (Nexus 5/Galaxy S4) auch nicht implementieren.
Kalle schrieb: > nee nee ... wieso? Meinst, dass da jemand am SPI rumschnüffelt? :D Also > das Problem wirst du immer haben zumal ists unwahrscheinlich. > Verschlüsselt ist wirklich nur das was durch die Luft geht. Mit dem > Reader IC rede ich Klartexr. Naja, wenn ich das Zeug hinterm Reader Chip nicht verschlüssle ist es auch kackegal, ob die Luftschnittstelle verschlüsselt ist oder nicht. Und die Schnittstelle zu verschlüssel ist ja kein Problem und bei den reader ICs auch vorgesehen. Bzgl. Mifare Classic haste natürlich Recht
Kalle schrieb: > Der Aufwand wäre mir zu hoch für nen Partykeller. Hab jetzt spontan aber > auch kein Shield gefunden, welches die Protokollbehandlung der Karten > abfängt bzw. ich weiß nicht ob es für den Arduino fertigen Code gibt. > Sorry, da muss ich passen. Es geht auch darum einfach mal was "damit" gemacht zu haben, mich interessiert die Technik halt einfach ;) Der Weg ist das Ziel und immerhin hab ich dann eine "modernes" Bezahlverfahren ;) Eine kleine Lib hab ich gefunden für die Ultralight (ohne C): http://learn.adafruit.com/adafruit-pn532-rfid-nfc/mifare Nur blicke ich nicht durch ob der PN532 die Ultralight C überhaupt unterstützt, weil es nirgends explizit erwähnt wird (dann müsste der Controller IC ja 3DES können)? In einem andere Datasheet eines NXP ICs waren einige Mifare Karten-Typen explizit aufgelistet. A. B. schrieb: > Naja, wenn ich das Zeug hinterm Reader Chip nicht verschlüssle ist es > auch kackegal, ob die Luftschnittstelle verschlüsselt ist oder nicht. Nunja die Daten durch die Luft kannst du viel leichter abfangen wie die am SPI. Am Drehkreuz der U-Bahn wirst du kaum an den SPI Bus kommen ohne großen Aufwand, die drahtlose Kommunikation abzufangen ist dagegen recht einfach ;)
Ich glaube nicht, dass die Standardreader DES können. Geschweige denn 3DES, was ja einfach nur 3xDES ist, da DES ja als "knackbar" gilt. Ein Indiz wäre auch, dass NXP die ICs in Kategorien aufteilt. Und z.B. unter den MIFARE SAMs ist "Ultralight C" zusammen mit den "DESfire" gelistet (http://www.nxp.com/products/identification_and_security/nfc_and_reader_ics/mifare_sams_secure_reader_ics/) Ich denke mal nicht, dass das mit dem PN532 geht. Wenns dir nur um das "machen" geht, dann nimm doch nen Standard Reader IC der nur Mifare unverschlüsselt kann und verlege die Krypto in den Mikrocontroller. Für die dsPICs gibts ganz anständige Libraries zu dem Thema. Dann wäre nämlich auch für ganz vorsichtige schon die SPI-Schnittstelle verschlüsselt ;-)
Kalle schrieb: > Ich denke mal nicht, dass das mit dem PN532 geht. So ich habe mal etwas recherchiert und bin auf den MFRC522 gestoßen. Dieser kann wohl auch verschlüsselte Karten lesen (wobei die Ultralight C nicht explizit aufgelistet werden, die DESFire jedoch schon!?) http://www.nxp.com/documents/data_sheet/MFRC522.pdf Zitat: > The MFRC522 supports all variants of the MIFARE Mini, MIFARE 1K, > MIFARE 4K, MIFARE Ultralight, MIFARE DESFire EV1 and MIFARE Plus RF > identification protocols Das praktische ist für diesen Chip gibt es bereits fertige Arduino Boards und Libs mit denen man zumindest Mifare Classic lesen kann. Wäre es denkbar den Code so zu erweitern dass auch Ultralight C gehen, also ist der IC dazu überhaupt technisch in der Lage?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.