So programmieren Sie NFC-Tags mit verschiedenen Chiptypen (NTAG, MIFARE und mehr)

 

Beim Schreiben eines Tags handelt es sich um drei separate Vorgänge, nicht um einen

 

Wenn Leute sagen, dass sie NFC-Tags programmieren möchten, beschreiben sie normalerweise drei verschiedene Dinge, die zufällig durch dieselbe Taste in einer Telefon-App ausgelöst werden.

 

Das erste istFormatierung. Dem Speicher eines NFC-Chips muss mitgeteilt werden, dass sein Benutzerbereich eine NDEF-Nachricht und keine beliebigen Bytes enthält. Dies erfolgt durch das Schreiben einer kleinen Datenstruktur, die als Capability-Container bezeichnet wird. Bei NTAG21x-Bauteilen erfolgt dies bereits auf Waferebene, sodass der Chip NDEF-formatiert ankommt und immer nur NDEF speichern kann. Bei MIFARE Classic und einigen anderen Chips müssen Sie die Formatierung durchführen und die Struktur landet in einem einmal-zeitlich-programmierbaren Bereich. Die Formatierung ist daher dauerhaft. Es gibt keinen Befehl zum Aufheben der Formatierung und kein Herstellertool, das Ihnen einen solchen Befehl bietet.

 

Das zweite istSchreiben der Nutzlast: eine NDEF-Nachricht, die einen oder mehrere Datensätze enthält, meist ein URI-Datensatz, der auf eine URL verweist. Dies ist der Teil, den sich jeder vorstellt. Payload-Schreibvorgänge sind normalerweise wiederholbar, weshalb ein Marketingteam ein Kampagnen-Tag sechs Monate später umleiten kann, ohne Hardware nachbestellen zu müssen.

 

Der dritte istKonfiguration: Passwortbytes, Sperrbits, Spiegeleinstellungen, Zugriffsbedingungen, Authentifizierungsschlüssel. Auf dieser Ebene liegen die unumkehrbaren Entscheidungen, und es ist die Ebene, die in keinem Verbraucher-Tutorial berührt wird. Wenn Sie vorhaben, NFC-Tags für alles zu programmieren, das eine Sicherheitsgrenze hat, ist die Konfigurationsebene das Projekt.

 

Wenn Sie diese drei im Kopf getrennt halten, können Sie verhindern, dass eine Charge verschrottet wird. Bei den meisten von uns diagnostizierten Schreibfehlern handelt es sich nicht um Nutzlastfehler. Es handelt sich um einen Formatierungs- oder Konfigurationszustand, von dessen Existenz jemand nicht wusste.

 

NFC-Tag-Chip-Typen im Vergleich, bevor Sie sie programmieren

 

Jede ernsthafte Entscheidung über die Programmierung von NFC-Tags im großen Maßstab beginnt mit dieser Tabelle, da die Speicherobergrenze und die Plattformunterstützung zum Zeitpunkt der Chipauswahl festgelegt werden und später nicht in der Software gepatcht werden können.

 

Chip	Benutzerspeicher	Typ des NFC-Forums	Werksseitiger NDEF-Status	Passwort-/Schlüsselschutz	iPhone NDEF lesen + schreiben
NTAG 213	144 Byte	Typ 2	Vor-formatiert	32-Bit-PWD / 16-Bit-PACK	Ja
NTAG 215	504 Byte	Typ 2	Vor-formatiert	32-Bit-PWD / 16-Bit-PACK	Ja
NTAG 216	888 Byte	Typ 2	Vor-formatiert	32-Bit-PWD / 16-Bit-PACK	Ja
MIFARE Ultralight EV1	48 oder 128 Byte	Typ 2	Formatierbar	32-Bit-PWD / 16-Bit-PACK	Ja
MIFARE Classic 1K	Insgesamt 1.024 Bytes, davon stehen nach Abzug des Herstellerblocks und 16 Sektortrailern etwa 716 für NDEF zur Verfügung	Kein NFC-Forum-Typ	Formatierbar, sektorbasiert-	CRYPTO-1-Sektorschlüssel A/B	NEIN
MIFARE DESFire EV3	2 KB bis 8 KB, dateibasiert-	Typ 4	Der Antrag muss erstellt werden	AES-128 / 3DES, Zugriffsrechte pro Datei	Ja
NTAG 424 DNA	Insgesamt 416 Byte, aufgeteilt in einen 32-Byte-Container, eine 256-Byte-NDEF-Datei und eine 128-Byte-geschützte Datendatei	Typ 4	Vor-bereitgestellte Dateien	Fünf AES-128-Schlüssel, gegenseitige Authentifizierung in drei Durchgängen	Ja

 

NTAG21x-Zahlen, Lock--Bit-Verhalten und Typ 2 / ISO/IEC 14443 Typ A-Konformität gemäßNXP NTAG213/215/216 Produktdatenblatt. MIFARE Classic 1K-Struktur gemäß NXP-Datenblatt MF1S50yyX (16 Sektoren × 4 Blöcke × 16 Bytes). DESFire EV3 pro MF3D(H)x3. NTAG 424 DNA-Speicherlayout proNXP.

 

Zwei Spalten entscheiden über die meisten Projekte, bevor eine Software ausgewählt wird: die Speicherobergrenze und die iPhone-Spalte. Was die Tabelle Ihnen nicht sagen kann, ist der Ertrag. Ein korrekt spezifizierter Chip erzeugt immer noch Ausschuss, wenn hinter dem Codierungsschritt kein Verifizierungsdurchlauf erfolgt, was Gegenstand der zweiten Hälfte dieses Artikels ist.

 

NTAG 213, 215 und 216: die Standardauswahl und ihre tatsächliche Obergrenze

 

Für etwa vier von fünf Inbound-Projekten ist diese Familie die richtige Antwort, und das Programmieren von NTAG 215 NFC-Tags zu erlernen dauert mit einer Telefon-App etwa neunzig Sekunden. Der Chip wird im NDEF--Format ausgeliefert, der Datensatztyp, der sich auf allen Mobiltelefonen einheitlich verhält, ist ein einfacher URI-Datensatz, und sowohl Android als auch iOS schreiben ihn ohne SDK-Arbeit.

 

 

Es ist auch die Familie hinter fast jedem digitalen Visitenkartenprogramm, bei dem eine einzelne vCard oder ein URL-Datensatz die gesamte Nutzlast darstellt und bei der das physische Format in der Regel wichtiger ist als der Chip. Die meisten dieser Bestellungen landen aufleere weiße PVC-NFC-Kartenstatt Aufklebern, denn die Karte muss einer Brieftasche standhalten und einen Druck aushalten.

 

Die Decke kommt schneller als erwartet. NTAG213 bietet Ihnen 144 Byte Benutzerspeicher und eine NDEF-Nachricht ist nicht nur Ihre URL. Es gibt einen TLV-Wrapper, einen Datensatz-Header, ein Typfeld und ein Längenfeld, bevor ein einzelnes Zeichen Ihrer Adresse gespeichert wird. Ein URI-Eintrag komprimiert gängige Präfixe wie zhttps://www.in ein einzelnes Byte, das zehn bis zwanzig Bytes wiederherstellt, und bei einem 144-Byte-Teil ist dieser Unterschied die Grenze zwischen Passen und Scheitern. Woran Teams hängen bleiben, ist nicht die URL selbst, sondern die Extras: Fügen Sie einen Textdatensatz für eine menschenlesbare Beschriftung hinzu, fügen Sie einen Android-Anwendungsdatensatz hinzu, damit das Tag eine App statt eines Browsers öffnet, und eine komfortable Nutzlast wird zu einem Überlauffehler.

 

Unsere eigene Faustregel, und so etwas lernt man erst, wenn man ein paar Millionen davon kodiert: Wenn die beabsichtigte URL einschließlich der Abfrageparameter etwa 90 Zeichen überschreitet, geben Sie NTAG213 nicht mehr an und wechseln Sie nach oben. Der Unterschied bei den Stückkosten zwischen 213 und 215 ist gering genug, dass sich das Risiko einer Neugestaltung mitten im Programm fast nie lohnt. Eine Kampagne, die später UTM-Parameter oder eine Seriennummer an jede Tag-URL anhängen möchte, stößt bei 213 an die Wand und nicht bei 215.

 

Der Passwortschutz dieser Familie ist genau zu verstehen, da er schwächer ist, als das Wort „Passwort“ vermuten lässt. Ein 32-Bit-PWD-Wert wird im Klartext übertragen und vom Chip überprüft, der den Schreibzugriff und optional den Lesezugriff ab einer ausgewählten Seite sperrt. Es verhindert, dass ein neugieriger Bürger Ihren Tag mit einem Telefon umschreibt. Es handelt sich nicht um eine kryptografische Kontrolle und sollte einem Client gegenüber niemals als eine solche beschrieben werden. Beachten Sie auch, dass es überhaupt nicht von jeder Generation unterstützt wird: Der ältere NTAG203 verfügt über keinerlei Passwortmechanismus, und in der Bibliotheksdokumentation wird ausdrücklich darauf hingewiesen, dass Schutzaufrufe dagegen einfach fehlschlagen (NFCPY-Dokumentation).

 

MIFARE Classic: Beschreibbar auf Android, praktisch nicht auf dem iPhone

 

Hier liegt die Kompatibilitätsfalle, die mehr NFC-Projekte zum Scheitern gebracht hat als jeder andere einzelne Faktor. Jeder, der fragt, wie man NDEF in MIFARE Classic schreibt, arbeitet bereits gegen den Kern des Formats: MIFARE Classic ist kein NFC-Forum-Tag-Typ, es ist eine ISO/IEC 14443-3A-Karte mit einem proprietären Sektor und einer Schlüsselstruktur, die älter ist als das NDEF-Ökosystem, und NDEF-Unterstützung existiert darauf nur durch eine darüber liegende Zuordnungskonvention.

 

 

Android berücksichtigt diese Konvention. iOS nicht. Apples Core NFC hat MIFARE Classic nie unterstützt, da die von der Plattform unterstützten MIFARE-Familien auf Ultralight, Plus und DESFire beschränkt sind, eine Position, die Entwickler wiederholt in Apples eigenen Foren bestätigt haben (Apple-Entwicklerforen). Da iOS den Speicher der Karte nicht direkt ansprechen kann, kann ein iPhone weder NDEF darauf schreiben noch darauf gespeicherte NDEF anzeigen.

 

Was dies bei der Auswertung so gefährlich macht, ist, dass MIFARE Classic-Tags auf einem iPhone nicht tot erscheinen. Die Karte verfügt über eine ISO 14443-A-UID, sodass die Shortcuts-App diese gerne als Automatisierungsauslöser akzeptiert und ein Hintergrundscan immer noch einen zuvor gespeicherten NDEF-Datensatz eines unterstützten Typs starten kann. Ein Beschaffungsleiter, der eine Probe auf seinem iPhone testet, sieht eine Antwort und meldet sich ab. Das beobachtete Verhalten hatte nichts mit dem Speicherinhalt des Tags zu tun, und der gesamte Ansatz bricht zusammen, sobald das Projekt URLs pro Einheit benötigt, die iPhones tatsächlich lesen können.

 

Die praktische Regel, die sich daraus ergibt: Wer die Programmierung von NFC-Tags für iPhone und Android vergleicht, sollte Abnahmetests auf beiden Plattformen mit dem Produktionschip durchführen, niemals nur auf Android und niemals auf einem Muster eines anderen Chips als dem auf der Bestellung.

 

Lassen Sie mich die Empfehlung ganz deutlich sagen, denn „es hängt von Ihrem Anwendungsfall ab“ ist hier keine nützliche Antwort. Wenn Ihre NFC-Tags von der Öffentlichkeit abgehört werden, geben Sie etwas außer MIFARE Classic an.

 

Für Teams, die sich bereits in einem klassischen-basierten Zugriffssystem befinden, reduziert sich die Entscheidung auf eine Variable und nicht auf die Tags. Es handelt sich um die verbleibende Nutzungsdauer Ihres Lesegeräte-Nachlasses. Wenn diese Leser noch zwei oder drei Jahre Zeit haben und kein Smartphone jemals den Berechtigungsnachweis erreichen wird, ist die Fortführung von Classic in einem geschlossenen Kreislauf eine vertretbare Entscheidung, und die praktischen Fragen werden eher IC-Sourcing und UID-Format als die Kodierungsmethode, die wir in unseren Anmerkungen behandelnBestellen von MIFARE 1K-Tags in einem installierten System. Wenn die Lesegeräte selbst innerhalb dieses Zeitfensters ausgetauscht werden müssen, geben Sie kein Geld für einen Übergangsausweis aus. Verschieben Sie den gesamten Bestand in einem Schritt auf einen AES-basierten Teil und übernehmen Sie die Kosten einmal.

 

Es gibt eine zweite Falle in derselben Familie, die so subtil ist, dass sie vollständige Qualitätssicherungszyklen übersteht. Durch das Hinzufügen eines Smart Poster-Wrappers zu einem Datensatz, den die gängigen Codierungstools als benutzerfreundliche Möglichkeit zum Anhängen eines Titels an eine URL bieten, ändert sich der Datensatztyp. Auf diese Weise verpackte Datensätze werden vom iOS-Hintergrundscan überhaupt nicht erfasst, unabhängig davon, was darin verschachtelt ist. Android-Tests bestehen auf jedem Gerät, iPhones tun nichts und es gibt nirgendwo eine Fehlermeldung, die diagnostiziert werden könnte.

 

Ultralight, DESFire und NTAG 424 DNA: Wo Programmierung zur Schlüsselverwaltung wird

 

MIFARE Ultralight EV1 kommt im Verhalten dem NTAG21x nahe und Sie programmieren darauf NFC-Tags auf die gleiche Weise, mit einem kleineren Speicherbudget von 48 oder 128 Bytes und der gleichen Passwort-Gate-Klasse. Es passiert nichts konzeptionell Neues.

 

DESFire und NTAG 424 DNA sind eine andere Disziplin. Bei diesen Typ-4-Teilen schreiben Sie keine Bytes in eine flache Speicherzuordnung, Sie arbeiten auf einem Dateisystem mit Zugriffsrechten pro-Datei und jeder sinnvolle Vorgang erfordert zunächst die Authentifizierung mit einem AES-128-Schlüssel. NTAG 424 DNA verfügt über fünf vom Kunden definierte AES-Schlüssel, verwendet eine gegenseitige Authentifizierung in drei Durchgängen für die geschützte Datendatei und verfügt über die Common Criteria EAL4-Zertifizierung sowohl für Hardware als auch für Software. Teams, die NFC-Tags zur Produktauthentifizierung statt zur einfachen Weiterleitung programmieren, suchen aufgrund einer Funktion normalerweise speziell nach diesem Teil.

 

Diese Funktion ist Secure Dynamic Messaging, oft als SUN geschrieben. Wenn diese Option aktiviert ist, ändert sich die NDEF-URL, die der Chip präsentiert, bei jedem einzelnen Tippen: Der Chip spiegelt seine UID und einen monoton steigenden Lesezähler in die URL, optional verschlüsselt, und hängt einen CMAC an, der mit einem Schlüssel berechnet wird, den nur Sie und der Chip besitzen. Ihr Backend kann dann ein echtes Tag von einer fotografierten URL unterscheiden und Tap Nummer 4 von Tap Nummer 4.000 unterscheiden.

 

Bei der richtigen Konfiguration geht es um die Spezifikation. Die Spiegelungsregeln sind nicht frei-: Wenn die PICC-Daten verschlüsselt sind, wird die Spiegelung der UID und des Lesezählers obligatorisch und nicht optional, die beiden werden immer zusammen übertragen und der CMAC muss am Ende der NDEF-Nachricht stehen. Entwerfen Sie Ihre URL-Struktur entsprechend diesen Einschränkungen und nicht umgekehrt, sonst werden die Offsets nicht aufgelöst und das Backend lehnt jeden Lesevorgang ab.

 

Der Fehler, den wir am häufigsten bei SUN-Bereitstellungen sehen, hat damit nichts zu tun. Jede öffentliche Referenzimplementierung und jeder Demoserver wird mit den werkseitigen -Standardschlüsseln-Nullschlüsseln ausgeliefert, denn nur so funktioniert eine Demo sofort. Wenn dagegen ein Prototyp projiziert wird, funktioniert der Prototyp und der Schlüsselrotationsschritt schafft es nie auf die Checkliste für den Start. Die Tags werden kryptografisch unverschlüsselt ausgegeben, während alle Beteiligten davon ausgehen, dass die Bereitstellung verschlüsselt ist. Aus diesem Grund überprüft unser eigenes Musterfreigabeverfahren die Schlüsseldiversifizierung auf den Produktionseinheiten und nicht auf dem, was für die Demo verwendet wurde.

 

Sechs Vorgänge, die Sie nach der Programmierung von NFC-Tags nicht mehr rückgängig machen können

 

Das Umschreiben von Nutzlasten ist günstig. Das sind sie nicht. Bei jeder der folgenden Entscheidungen handelt es sich um eine Entscheidung, die eine Reihe von Tags in einen Anlagewert umwandelt, und bei jeder einzelnen handelte es sich um die Ursache für verschrottete Bestände, die wir persönlich ersetzen mussten.

 

Betrieb	Was es bewirkt	Warum es nicht rückgängig gemacht werden kann	Wann es geplant werden sollte
NDEF-Formatierung	Schreibt den Capability-Container	Landet in einem -zeitlich-programmierbaren Speicher	Im Werk, nachdem der Chiptyp bestätigt wurde
Statische Sperrbits	Sperrt die ersten 16 Seiten auf Typ-2-Chips	Sperrbits werden nur -gesetzt und können nicht zurückgesetzt werden	Erst nach Freigabe des endgültigen Inhalts
Dynamische Sperrbits	Decken 96 Datenbytes auf NTAG213, 456 auf NTAG215 und 840 auf NTAG216 ab, mit einer Granularität von 2 Seiten auf NTAG213 und 16 Seiten auf NTAG215 und NTAG216, gemäß dem oben genannten NXP-Datenblatt	Gleicher Satz-nur Mechanismus, gleiche Beständigkeit	Gleiches Tor wie statische Schlösser
Schreibgeschützter Schalter-	Setzt das NDEF-Schreibflag dauerhaft	Es existiert kein Umkehrbefehl	Niemals vor Abschluss des Feldversuchs
LRP-Modus auf NTAG 424 DNA	Schaltet AES auf einen auslaufsicheren -Leckagebetrieb um	Aktiviert durch SetConfiguration, ohne Pfad zurück zum AES-Modus	Nur wenn ein dokumentiertes Bedrohungsmodell dies erfordert
Schlüsselwechsel ohne Treuhandkonto	Ersetzt werkseitige AES-Schlüssel	Der Chip verfügt über keinen Wiederherstellungspfad, wenn der neue Schlüssel verloren geht	Erst einmal wird die Schlüsselverwahrung offiziell übertragen

 

Diese Seitengranularität ist das praktische Detail, das die meisten Leute übersehen, wenn sie fragen, wie man ein NFC-Tag nach der Programmierung sperrt. Beim Sperren handelt es sich nicht um einen einzelnen Alles--oder-Nichts-Schalter. Auf NTAG215 und NTAG216 können Sie Blöcke von 16 Seiten festlegen, wodurch ein gemischtes Layout realisierbar ist: ein Seriennummernbereich, der werkseitig gesperrt ist, ein Kampagnen-URL-Bereich, der für das Marketingteam beschreibbar bleibt. Auf NTAG213 beträgt die Granularität zwei Seiten, feiner, aber auf einer viel kleineren Karte. Die Festlegung der Grenze ist eine Entwurfsaufgabe und muss vor dem Codierungslauf erfolgen, nicht danach.

 

Es lohnt sich, sich die Gewohnheit anzueignen, das Kodierungstor vom Verriegelungstor zu trennen. Wir raten Kunden von einer Sperrung zum Zeitpunkt der Bestellung ab, da dies rein kommerzieller und nicht technischer Natur ist.

 

In unserer Bestellhistorie handelt es sich bei der häufigsten Anfrage nach{0}}Lieferung nicht um eine Mängelrüge, sondern um eine Änderung des Zielorts, und sie kommt gehäuft innerhalb des ersten Dienstjahres vor. Übliche Auslöser sind eine Landingpage-Migration oder eine Agenturübergabe, beides ist zum Zeitpunkt der Auftragserteilung nicht sichtbar. Um diesbezüglich Maßnahmen zu ergreifen, benötigen Sie keine Fehlerstatistiken von irgendjemandem, denn die Asymmetrie entscheidet von selbst: Ein entsperrter Tag, der niemals geändert werden muss, kostet Sie nichts, während ein gesperrter Tag, der geändert werden muss, einen kompletten Ersatzauftrag plus den Neuinstallationsaufwand kostet. Programmieren Sie zuerst die NFC-Tags, führen Sie den Feldversuch durch und sperren Sie sie anschließend.

 

Auf der Rechnung steht die Überprüfung des Chips

 

 

Die Chip-Authentizität stellt in dieser Kategorie kein paranoides Problem dar, es handelt sich um einen routinemäßigen Prüfgegenstand-und er gehört zum selben QC-Schritt wie jede andere Prüfung, die Sie durchführen, bevor Sie NFC-Tags in Produktionsmengen programmieren. Die NTAG-, MIFARE-, Ultralight- und ICODE-Familien von NXP tragen jeweils eine ECC-basierte Originalitätssignatur, die bei der Chipproduktion geschrieben wird, 32 Bytes auf NTAG21x-Teilen, die zurückgelesen und anhand des öffentlichen Schlüssels des Herstellers verifiziert werden kann. Ein Tag, der sich perfekt verhält, kann diese Prüfung trotzdem nicht bestehen.

 

Dies passiert häufiger, als der Markt zugibt. Ingenieure, die NTAG21x-Tags über allgemeine Einzelhandelskanäle kaufen, haben der Community des Herstellers berichtet, dass Muster genau wie angegeben funktionieren, einschließlich Gegenspiegelung, sich jedoch als Klon-Silizium unter Originalitätsprüfung melden. Die veröffentlichte Antwort von NXP lautet, dass solche Teile nicht unterstützt werden und für den sicheren Einsatz ungeeignet sind, da der IC selbst anfällig sein könnte (NXP-Community).

 

Die betrieblichen Konsequenzen sind enger als angenommen und es lohnt sich, sie genau anzugeben. Wenn es sich bei Ihrer Anwendung um eine Marketing-Weiterleitung handelt, wird Ihnen ein Klon-Chip ausreichend dienen, und es ist Ihnen möglicherweise egal. Wenn Ihre Anwendung eine Authentifizierung, einen Manipulationsnachweis oder einen gegen Ihren eigenen Kunden gerichteten Anspruch auf Fälschungssicherheit beinhaltet, macht ein nicht überprüfbarer Chip die gesamte Prämisse ungültig, und keine korrekte Codierung gleicht dies aus. Mit einer Lese-App dauert die Verifizierung pro Probe nur wenige Sekunden und gehört zu Ihrem eingehenden QC-Verfahren und nicht zu einer Post-Mortem-Analyse. Verwandte Lektüre für alle, deren Schreibvorgang abgeschlossen ist, deren Leser aber schweigt:Warum ein geklonter Aufkleber gut liest und trotzdem an der Tür scheitert.

 

Die MIFARE Classic-Sicherheitsfrage, ehrlich gesagt

 

Wer heute MIFARE Classic spezifiziert, sollte von der aktuellen Forschungslage ausgehen und nicht von dem Ruf, den die Plattform vor einem Jahrzehnt hatte.

 

Im Jahr 2024 gelang es einer Studie des FM11RF08S, eines im Jahr 2020 veröffentlichten MIFARE Classic-kompatiblen Chips mit Gegenmaßnahmen, die speziell darauf ausgelegt sind, allen bekannten Nur-Karten-Angriffen zu widerstehen, diese Gegenmaßnahmen zunichte zu machen und dabei eine Hardware-Hintertür aufzudecken. Die Hintertür ermöglicht es jeder Partei, die davon Kenntnis hat, jeden benutzerdefinierten Schlüssel auf der Karte innerhalb von Minuten nach dem physischen Zugriff zu kompromittieren, und dies gilt auch dann, wenn die Schlüssel pro Karte vollständig unterschiedlich sind (Kryptologie-ePrint-Archiv). Zugehörige Hintertürschlüssel wurden in einer größeren Anzahl von Teilen identifiziert, darunter frühere Fudan-Generationen und bestimmte NXP- und Infineon-Geräte.

 

Lesen Sie das sorgfältig durch, bevor Sie daraus falsche Schlussfolgerungen ziehen. Dies ist kein Argument, dem jeder, der MIFARE Classic verwendet, morgen ausgesetzt sein wird, und wir stellen es auch nicht als solches dar. Millionen von Classic-Zugangsdaten werden in Umgebungen mit geringen Folgen eingesetzt, in denen das Klonen einer Karte einem Angreifer Zugang zu einem Schließfach im Fitnessstudio verschafft. Es ist ein Argument dafür, dass der Begriff „sicher“ nirgends in einem Spezifikationsdokument neben dieser Chipfamilie erscheinen sollte und dass jeder, der NFC-Tags für Hotelzimmer, Bürozugang oder bargeldloses Bezahlen auf Classic-Chips programmieren möchte, eine Migration zu einem AES-basierten Teil in denselben Budgetzyklus einkalkulieren sollte.

 

NFC-Tags in großen Mengen programmieren: Was sich über tausend Einheiten ändert

 

Alles, was bisher beschrieben wurde, lässt sich schlecht skalieren. Eine Telefon-App schreibt jeweils ein Tag, ohne Batch-Aufzeichnung, ohne Verifizierungsdurchlauf und ohne Möglichkeit, im Nachhinein nachzuweisen, welche URL zu welcher physischen Einheit gelangt ist. Es gibt drei Ebenen für die Massenprogrammierung von NFC-Tags, und der Übergang zwischen ihnen ist eher betrieblicher als technischer Natur.

 

Die erste Stufe besteht aus einem Telefon und einer App, die für etwa hundert Einheiten nutzbar sind und für Prototypen und interne Piloten geeignet sind.

 

Auf der zweiten Ebene landen die meisten internen-Teams: Sie programmieren NFC-Tags mit einem Lese-/Schreibgerät auf einem Desktop, gesteuert durch eine Batchdatei, normalerweise über einen USB-Encoder der ACR12xx- oder uTrust-Klasse. Es funktioniert gut, bis der Chip wechselt. Das in diesem Bereich weit verbreitete Open-Source-Batch-Tool zielt beispielsweise speziell auf den ACR122 ab und codiert nur MIFARE Ultralight und Ultralight C, bei denen es sich um Typ-2-Teile handelt. Wenn Sie dieses Projekt also auf einen Typ-4-Chip verschieben, müssen Sie das Tool neu erstellen, anstatt eine Konfigurationsdatei zu bearbeiten. Wenn Sie immer noch Hardware für diese Stufe auswählen, ist unsereUSB- und Desktop-NFC-Lese--Schreibgerät-Reihedeckt die Lesermodelle ab, die diese Toolchains erwarten.

 

Branchenübliche Praxis für die dritte Stufe ist die Vorcodierung während der Herstellung. Dabei handelt es sich um die Stufe, von der die meisten Käufer nicht wissen, dass sie existiert. In unseren Linien in einem 3.600 m² großen Werk findet die Kodierung zwischen dem Chipbonden und der Endmontage statt, auf Geräten, die jedes Tag in Position bringen, den Datensatz schreiben und ihn zurücklesen, bevor das Tag weiterbewegt wird. Der Verifizierungsdurchlauf ist der springende Punkt. Ein Tag, dessen Zurücklesen fehlschlägt, wird in der Zeile zurückgewiesen, anstatt von einem Kunden vor Ort entdeckt zu werden, und der Stapel verlässt ihn mit einer Zuordnungsdatei, die jede UID oder TID mit dem genauen darin geschriebenen Inhalt verknüpft, was Ihr CMS oder Ihre Analyseplattform am ersten Tag benötigt. Die automatisierte Bonding-Kapazität in fünf Produktionslinien liegt bei über 100.000 Chips pro Tag, sodass die Kodierung nicht zur Einschränkung der Vorlaufzeit wird.

 

Was diese Beschreibung bewusst auslässt, ist die Akzeptanzschwelle. Die Read-Back-Verifizierung ist ein Pass/Fail-Gate, aber die Fehlerrate, die Sie vertraglich akzeptieren sollten, hängt von der Chipfamilie, dem Formfaktor und davon ab, ob das Tag anschließend laminiert wird. Ein Anti--Metallaufkleber und eine PVC-Karte verhalten sich auf derselben Linie nicht gleich. Diese Zahl gehört in ein Angebot für Ihren spezifischen Build, nicht in einen Artikel, und sie ist das Erste, was wir festlegen, wenn ein neues Programm startet.

 

Es lohnt sich, klar anzugeben, wo wir unsere eigene Fähigkeitsgrenze ziehen, da die Teilelieferanten normalerweise verschwimmen. Wir programmieren NFC-Tags mit Ihrer URL-Vorlage vor-, serialisieren sie pro Einheit, überprüfen jedes Tag und liefern die Zuordnungsdatei. Wir stellen die von Ihnen bereitgestellten AES-Schlüssel bereit. Wir werden Ihre Produktionsschlüssel nicht aufbewahren, wir werden Ihr Validierungs-Backend nicht betreiben und wir werden Ihnen nicht sagen, dass eine Fabrik ein Sicherheitsdesign auf Anwendungsebene korrekt machen kann. Dieser Teil gehört Ihnen, und jeder Lieferant, der etwas anderes behauptet, verkauft Ihnen eine Risikoübertragung, die es nicht gibt.

 

Neun Fragen, die vor dem Codierungslauf geklärt werden müssen

 

Führen Sie dies vor der Bestellung durch, nicht nach Eintreffen der Muster. Jeder Gegenstand hat mindestens ein Projekt beendet, um dessen Rettung wir gebeten wurden.

 

#	Frage	Warum es der Chip entscheidet
1	Werden iPhones auf diese Tags tippen?	Entfernt MIFARE Classic vollständig aus der Betrachtung
2	Wie lang ist die vollständige URL, einschließlich zukünftiger Parameter?	Legt den Boden auf NTAG213, 215 oder 216 fest
3	Reicht ein Datensatz oder benötigen Sie zusätzlich einen Text- oder App-Datensatz?	Zusätzliche Datensätze verbrauchen dasselbe Speicherbudget
4	Wird sich das Ziel während der Lebensdauer des Tags ändern?	Bestimmt, ob das Sperren jemals akzeptabel ist
5	Erhebt die Anwendung einen Authentizitätsanspruch gegenüber Endbenutzern?	Leitet Sie zu NTAG 424 DNA oder DESFire
6	Wer hält und dreht die AES-Schlüssel?	Muss zugewiesen werden, bevor ein Schlüssel geändert wird
7	Was ist das Annahmekriterium für eine gelieferte Charge?	Definiert, ob die Rückleseüberprüfung vertraglich ist
8	Benötigen Sie eine UID--zu-Inhaltszuordnungsdatei?	Muss vor dem Lauf angegeben werden, nicht danach angefordert werden
9	Ist die Überprüfung der Originalität der Signatur Teil der eingehenden Qualitätskontrolle?	Legt fest, ob die Chipbeschaffung überprüfbar ist

 

Teams, die alle neun Fragen beantworten können, erzielen in der Regel beim ersten Versuch einen sauberen Produktionslauf. Teams, die sechs von neun Antworten beantworten können, entdecken die restlichen drei normalerweise auf kostspielige Weise.

 

Die neun Fragen sind die allgemeine Version. Diejenige, von der wir tatsächlich ausgehen, fügt eine zehnte Spalte hinzu, die Antwort, die für Ihren Build und nicht allgemein richtig ist, und diese Spalte hängt von Dingen ab, die dieser Artikel nicht sehen kann: Ihr Mobilteilmix, Ihre Leserausstattung, Ihr Laminierungsprozess und ob die Serialisierung sequentiell oder zufällig erfolgen muss. Senden Sie uns die ersten neun Antworten und wir senden Ihnen die kommentierte Version entsprechend Ihrer Spezifikation zurück.

 

Wohin dies einen Käufer führt

 

Es gibt kein allgemeines Verfahren zum Programmieren von NFC-Tags, sondern nur ein Verfahren pro Chip, pro Plattform, pro Volumen. Wählen Sie zuerst den Chip gegen die Speicherobergrenze und die iPhone-Frage. Behandeln Sie Formatierung, Nutzlast und Konfiguration als drei separate Tore. Verriegeln Sie niemals vor einem Feldversuch. Überprüfen Sie die Originalität eingehender Proben. Ab tausend Einheiten sollten Sie aufhören, über Apps nachzudenken, und stattdessen über Verifizierung und Rückverfolgbarkeit nachdenken.

 

Wenn eine Spezifikation bereits entworfen wurde, überprüfen wir sie gerne anhand der oben genannten Chipbeschränkungen und kennzeichnen alles, was die Produktion nicht übersteht. Außerdem stehen kostenlose Muster zum Testen auf Ihren tatsächlichen Lesegeräten und Mobiltelefonen zur Verfügung. Sie können auch mit dem beginnenNFC-Tag-Formate werden von uns vor-programmiert und-verifiziertwenn die Chip-Entscheidung noch offen ist, oderSenden Sie die URL-Struktur und das Zielvolumen für eine Codierungsüberprüfungwenn es schon behoben ist.

 

FAQ