NFC-tags programmeren met verschillende chiptypen (NTAG, MIFARE en meer)

 

Het schrijven van een tag is drie afzonderlijke handelingen, niet één

 

Wanneer mensen zeggen dat ze NFC-tags willen programmeren, beschrijven ze meestal drie verschillende dingen die toevallig worden geactiveerd door dezelfde knop in een telefoonapp.

 

De eerste isopmaak. Het geheugen van een NFC-chip moet erop worden gewezen dat het gebruikersgebied een NDEF-bericht bevat in plaats van willekeurige bytes. Dit wordt gedaan door een kleine gegevensstructuur te schrijven die bekend staat als de capaciteitscontainer. Bij NTAG21x-onderdelen gebeurt dit al op waferniveau, dus de chip arriveert NDEF-geformatteerd en kan alleen NDEF bevatten. Op MIFARE Classic en sommige andere chips is formatteren iets dat u uitvoert, en de structuur komt terecht in een een-tijd-programmeerbaar gebied. De opmaak is dus permanent. Er is geen unformat-opdracht, en geen leveranciertool die u er een geeft.

 

De tweede ishet schrijven van de lading: een NDEF-bericht dat een of meer records bevat, meestal een URI-record dat naar een URL verwijst. Dit is het deel dat iedereen fotografeert. Payload-schrijfbewerkingen zijn normaal gesproken herhaalbaar. Daarom kan een marketingteam een ​​campagnetag zes maanden later omleiden zonder de hardware opnieuw te bestellen.

 

De derde isconfiguratie: wachtwoordbytes, lock-bits, mirror-instellingen, toegangsvoorwaarden, authenticatiesleutels. Deze laag is waar de onomkeerbare beslissingen leven, en het is de laag die geen enkele consumententutorial raakt. Als u van plan bent NFC-tags te programmeren voor iets met een beveiligingsgrens eromheen, is de configuratielaag het project.

 

Door deze drie in je hoofd gescheiden te houden, voorkom je dat een batch wordt gesloopt. De meeste schrijffouten die we diagnosticeren, zijn geen fouten in de payload. Ze zijn een opmaakstatus of een configuratiestatus waarvan iemand niet wist dat deze bestond.

 

NFC-tagchiptypen vergeleken voordat u ze programmeert

 

Elke serieuze beslissing over het programmeren van NFC-tags op grote schaal begint met deze tabel, omdat geheugenplafond en platformondersteuning worden ingesteld op het moment van chipselectie en later niet in de software kunnen worden gepatcht.

 

Chip	Gebruikersgeheugen	NFC-forumtype	Fabrieks-NDEF-status	Wachtwoord-/sleutelbeveiliging	iPhone NDEF lezen + schrijven
NTAG 213	144 bytes	Type 2	Vooraf-geformatteerd	32-bits PWD / 16-bits PACK	Ja
NTAG 215	504 bytes	Type 2	Vooraf-geformatteerd	32-bits PWD / 16-bits PACK	Ja
NTAG 216	888 bytes	Type 2	Vooraf-geformatteerd	32-bits PWD / 16-bits PACK	Ja
MIFARE Ultralichte EV1	48 of 128 bytes	Type 2	Opmaakbaar	32-bits PWD / 16-bits PACK	Ja
MIFARE Klassiek 1K	In totaal 1.024 bytes, ongeveer 716 beschikbaar voor NDEF zodra het fabrikantblok en 16 sectortrailers zijn afgetrokken	Geen NFC-forumtype	Opmaakbaar, sector-gebaseerd	CRYPTO-1 sectorsleutels A/B	Nee
MIFARE DESFire EV3	2 KB tot 8 KB, op bestand-gebaseerd	Type 4	Er moet een applicatie worden aangemaakt	AES-128 / 3DES, toegangsrechten per bestand	Ja
NTAG 424-DNA	Totaal 416 bytes, opgesplitst in een capaciteitscontainer van 32 bytes, een NDEF-bestand van 256 bytes en een beveiligd gegevensbestand van 128 bytes	Type 4	Vooraf-ingerichte bestanden	Vijf AES-128-sleutels, wederzijdse authenticatie in 3 stappen	Ja

 

NTAG21x-cijfers, lock-bit-gedrag en conformiteit met Type 2 / ISO/IEC 14443 Type A volgens deNXP NTAG213/215/216 productgegevensblad. MIFARE Klassieke 1K-structuur volgens NXP-gegevensblad MF1S50yyX (16 sectoren × 4 blokken × 16 bytes). DESFire EV3 per MF3D(H)x3. NTAG 424 DNA-geheugenindeling perNXP.

 

Twee kolommen bepalen de meeste projecten voordat er software wordt gekozen: het geheugenplafond en de iPhone-kolom. Wat de tabel u niet kan vertellen, is de opbrengst. Een correct gespecificeerde chip produceert nog steeds uitval als de coderingsstap geen verificatiepas achter zich heeft, waarover de tweede helft van dit artikel gaat.

 

NTAG 213, 215 en 216: de standaardkeuze en het echte plafond

 

Voor grofweg vier van de vijf inkomende projecten is deze familie het juiste antwoord, en het leren programmeren van NTAG 215 NFC-tags duurt ongeveer negentig seconden met een telefoonapp. De chip wordt NDEF-geformatteerd verzonden, het recordtype dat zich op elke handset consistent gedraagt ​​is een gewone URI-record, en zowel Android als iOS schrijven dit zonder enig SDK-werk.

 

 

Het is ook de familie achter bijna elk programma voor digitale visitekaartjes, waarbij een enkele vCard- of URL-record de volledige payload vertegenwoordigt, en waarbij het fysieke formaat doorgaans belangrijker is dan de chip. De meeste van die bestellingen komen terechtblanco witte PVC NFC-kaartenin plaats van stickers, omdat de kaart in een portemonnee moet passen en een afdruk moet hebben.

 

Het plafond komt sneller dan mensen verwachten. NTAG213 geeft u 144 bytes gebruikersgeheugen, en een NDEF-bericht is niet alleen uw URL. Er is een TLV-wrapper, een recordkop, een typeveld en een lengteveld voordat een enkel teken van uw adres wordt opgeslagen. Een URI-record comprimeert algemene voorvoegsels zoalshttps://www.in één byte, die tien tot twintig bytes terugkrijgt, en op een deel van 144-bytes is dat verschil de grens tussen passend en falend. Waar teams betrapt worden, is niet de URL zelf, maar de extra's: voeg een tekstrecord toe voor een voor mensen leesbaar label, voeg een Android-applicatierecord toe zodat de tag een app opent in plaats van een browser, en een comfortabele payload wordt een overflow-fout.

 

Onze eigen vuistregel, en dit soort dingen leer je alleen door een paar miljoen hiervan te coderen: als de beoogde URL inclusief queryparameters ongeveer 90 tekens overschrijdt, stop dan met het specificeren van NTAG213 en ga omhoog. Het verschil in kosten per eenheid tussen 213 en 215 is zo klein dat het bijna nooit het risico van een herontwerp van het middenprogramma waard is. Een campagne die later UTM-parameters of een serienummer aan elke tag-URL wil toevoegen, zal op 213 tegenkomen en niet op 215.

 

Wachtwoordbeveiliging voor dit gezin is de moeite waard om precies te begrijpen, omdat het zwakker is dan het woord 'wachtwoord' suggereert. Een 32-bits PWD-waarde wordt transparant verzonden en gecontroleerd door de chip, die schrijftoegang en optioneel leestoegang vanaf een gekozen pagina mogelijk maakt. Het voorkomt dat een nieuwsgierig lid van het publiek uw tag met een telefoon herschrijft. Het is geen cryptografische controle en mag nooit als zodanig aan een cliënt worden beschreven. Merk ook op dat niet elke generatie dit helemaal ondersteunt: de oudere NTAG203 heeft helemaal geen wachtwoordmechanisme, en bibliotheekdocumentatie is expliciet dat beschermingsoproepen ertegen eenvoudigweg mislukken (nfcpy-documentatie).

 

MIFARE Classic: beschrijfbaar op Android, effectief afwezig op iPhone

 

Hier is de compatibiliteitsval die meer NFC-projecten heeft beëindigd dan welke andere factor dan ook. Iedereen die vraagt ​​hoe NDEF naar MIFARE Classic moet worden geschreven, werkt al tegen de kern van het formaat in: MIFARE Classic is geen NFC Forum-tagtype, het is een ISO/IEC 14443-3A-kaart met een eigen sector- en sleutelstructuur die dateert van vóór het NDEF-ecosysteem, en NDEF-ondersteuning daarop bestaat alleen via een kaartconventie die daar bovenop is gelaagd.

 

 

Android handelt die conventie af. iOS niet. Apple's Core NFC heeft MIFARE Classic nooit ondersteund, waarbij de door het platform ondersteunde MIFARE-families beperkt zijn tot Ultralight, Plus en DESFire, een standpunt dat ontwikkelaars herhaaldelijk hebben bevestigd op Apple's eigen forums (Apple ontwikkelaarsforums). Omdat iOS het geheugen van de kaart niet rechtstreeks kan adresseren, kan een iPhone er geen NDEF naar schrijven en de erop opgeslagen NDEF niet weergeven.

 

Wat dit tijdens de evaluatie zo gevaarlijk maakt, is dat MIFARE Classic-tags op een iPhone niet dood lijken. De kaart presenteert een ISO 14443-A UID, dus de Shortcuts-app accepteert deze graag als automatiseringstrigger, en scannen op de achtergrond kan nog steeds een eerder opgeslagen NDEF-record van een ondersteund type starten. Een inkoopleider die een monster op zijn iPhone test, ziet een reactie en tekent af. Het gedrag dat ze zagen had niets te maken met de geheugeninhoud van de tag, en de hele aanpak stort in op het moment dat het project URL's per eenheid nodig heeft die iPhones daadwerkelijk kunnen lezen.

 

De praktische regel die hieruit valt: iedereen die het programmeren van NFC-tags voor iPhone versus Android vergelijkt, moet acceptatietests uitvoeren op beide platforms met de productiechip, nooit op Android alleen, en nooit op een voorbeeld van een andere chip dan die op de aankooporder.

 

Laat me bot zijn over de aanbeveling, want "het hangt af van uw gebruiksscenario" is hier geen nuttig antwoord. Als uw NFC-tags door het publiek worden afgeluisterd, specificeer dan alles behalve MIFARE Classic.

 

Voor teams die al gebruik maken van een klassiek-gebaseerd toegangssysteem, wordt de beslissing teruggebracht tot één variabele, en niet de tags. Het is de resterende levensduur van uw lezersdomein. Als die lezers nog twee of drie jaar te gaan hebben en geen enkele smartphone ooit de inloggegevens zal aanraken, is doorgaan met Classic in een gesloten lus een verdedigbare beslissing, en de praktische vragen worden IC-sourcing en UID-formaat in plaats van de coderingsmethode, wat we behandelen in onze opmerkingen overMIFARE 1K-tags bestellen in een geïnstalleerd systeem. Als de lezers binnen dat venster zelf aan vervanging toe zijn, geef dan geen geld uit aan een overgangsreferentie. Verplaats het hele landgoed in één stap naar een op AES-gebaseerd onderdeel en neem de kosten in één keer op.

 

Er is nog een tweede valkuil in dezelfde familie, subtiel genoeg om volledige QA-cycli te overleven. Door een Smart Poster-wrapper aan een record toe te voegen, die de gebruikelijke coderingstools bieden als een vriendelijke manier om een ​​titel aan een URL te koppelen, wordt het recordtype gewijzigd. Records die op die manier zijn verpakt, worden helemaal niet opgepikt door iOS-achtergrondscans, ongeacht wat erin is genest. Android-tests slagen op elk apparaat, iPhones doen niets en er is nergens een foutmelding om te diagnosticeren.

 

Ultralight, DESFire en NTAG 424 DNA: waar programmeren sleutelbeheer wordt

 

MIFARE Ultralight EV1 zit qua gedrag dicht bij NTAG21x en je programmeert NFC-tags erop op dezelfde manier, met een kleiner geheugenbudget van 48 of 128 bytes en dezelfde klasse van wachtwoordpoort. Conceptueel gebeurt er niets nieuws.

 

DESFire en NTAG 424 DNA zijn een andere discipline. Op deze Type 4-onderdelen schrijft u geen bytes in een platte geheugenkaart, u werkt op een bestandssysteem met per-bestandstoegangsrechten, en voor elke betekenisvolle bewerking is eerst authenticatie met een AES-128-sleutel vereist. NTAG 424 DNA beschikt over vijf door de klant gedefinieerde AES-sleutels, gebruikt wederzijdse authenticatie in drie stappen voor het beschermde gegevensbestand en beschikt over Common Criteria EAL4-certificering op zowel hardware als software. Teams die NFC-tags programmeren voor productauthenticatie in plaats van eenvoudige omleiding, zijn meestal specifiek naar dit onderdeel op zoek vanwege één functie.

 

Die functie is Secure Dynamic Messaging, vaak geschreven als SUN. Als deze is ingeschakeld, presenteert de chip de NDEF-URL bij elke tik: de chip weerspiegelt zijn UID en een monotoon stijgende leesteller in de URL, optioneel gecodeerd, en voegt een CMAC toe die is berekend met een sleutel die alleen jij en de chip bevatten. Uw backend kan dan een echte tag onderscheiden van een gefotografeerde URL, en kan kraannummer 4 onderscheiden van kraannummer 4.000.

 

Het correct configureren is waar de specificatie bijt. De spiegelregels zijn niet vrij-: wanneer de PICC-gegevens zijn gecodeerd, wordt het spiegelen van de UID en de leesteller verplicht in plaats van optioneel, de twee reizen altijd samen en de CMAC moet aan het einde van het NDEF-bericht staan. Ontwerp uw URL-structuur rond deze beperkingen, en niet andersom, anders zullen de verschuivingen niet worden opgelost en zal de backend elke lezing weigeren.

 

De mislukking die we het vaakst zien bij SUN-implementaties heeft daar niets mee te maken. Elke openbare referentie-implementatie en demoserver wordt geconfigureerd met de fabrieksinstellingen-allemaal-nulsleutels, want dat is wat ervoor zorgt dat een demo direct werkt. Projecten prototypen daartegenover, het prototype werkt, en de sleutelrotatiestap komt nooit op de lanceringschecklist. De tags worden cryptografisch naakt verzonden, terwijl alle betrokkenen denken dat de implementatie gecodeerd is. Daarom controleert onze eigen voorbeeldvrijgaveprocedure de sleuteldiversificatie op de productie-eenheden in plaats van op wat er ook voor de demo werd gebruikt.

 

Zes handelingen die u niet meer kunt terugdraaien nadat u NFC-tags heeft geprogrammeerd

 

Het herschrijven van de payload is goedkoop. Dit zijn niet. Elk van de onderstaande tags is een beslissing die een reeks tags omzet in een vast actief, en elk van deze tags is de oorzaak geweest van de afgedankte inventaris die we persoonlijk hebben moeten vervangen.

 

Operatie	Wat het doet	Waarom het niet ongedaan kan worden gemaakt	Wanneer het gepland moet worden
NDEF-opmaak	Schrijft de capaciteitscontainer	Komt terecht in een-tijdelijk-programmeerbaar geheugen	In de fabriek, nadat het chiptype is bevestigd
Statische slotbits	Vergrendelt de eerste 16 pagina's op Type 2-chips	Lockbits worden alleen ingesteld-en kunnen niet worden gereset	Pas nadat de definitieve inhoud is afgetekend
Dynamische slotbits	Bestrijk 96 databytes op NTAG213, 456 op NTAG215 en 840 op NTAG216, met een granulariteit van 2 pagina's op NTAG213 en 16 pagina's op NTAG215 en NTAG216, volgens het hierboven aangehaalde NXP-gegevensblad	Hetzelfde vaste-enige mechanisme, dezelfde duurzaamheid	Dezelfde poort als statische sloten
Alleen-lezen-schakelaar	Stelt de NDEF-schrijfvlag permanent in	Er bestaat geen omgekeerd commando	Nooit vóór voltooiing van de veldproef
LRP-modus op NTAG 424 DNA	Schakelt AES over naar lek--veerkrachtige werking	Mogelijk gemaakt door SetConfiguration, zonder pad terug naar de AES-modus	Alleen als een gedocumenteerd dreigingsmodel dit vereist
Sleutelwissel zonder borg	Vervangt fabrieks-AES-sleutels	De chip heeft geen herstelpad als de nieuwe sleutel verloren gaat	Pas nadat de sleutelbewaring formeel is toegewezen

 

Die granulariteit van de pagina is het praktische detail dat de meeste mensen missen als ze vragen hoe ze een NFC-tag kunnen vergrendelen na het programmeren. Vergrendelen is geen enkele alles-of-niets-schakelaar. Op NTAG215 en NTAG216 kunt u blokken van 16 pagina's vergrendelen, wat een gemengde lay-out haalbaar maakt: een serienummergebied dat in de fabriek is vergrendeld, een campagne-URL-gebied dat beschrijfbaar blijft voor het marketingteam. Op NTAG213 bedraagt ​​de granulariteit twee pagina's, fijner maar op een veel kleinere kaart. Het bepalen van de grens is een ontwerptaak ​​en moet vóór de coderingsrun gebeuren, niet erna.

 

De gewoonte die de moeite waard is om te ontwikkelen, is het scheiden van de coderingspoort en de vergrendelingspoort. We raden klanten af ​​om op het moment van bestelling te vergrendelen, en de reden is eerder commercieel dan technisch.

 

In onze bestelgeschiedenis is het meest voorkomende verzoek na- levering geen claim over een defect, maar een wijziging van de bestemming, en het clustert binnen het eerste servicejaar. De gebruikelijke triggers zijn een migratie van een landingspagina of een overdracht van een bureau, maar geen van beide is zichtbaar op het moment dat de bestelling wordt geplaatst. U hebt de faalstatistieken van iemand anders nodig om hierop actie te ondernemen, omdat de asymmetrie dit zelf bepaalt: een ontgrendelde tag die nooit hoeft te worden gewijzigd, kost u niets, terwijl een vergrendelde tag die moet worden gewijzigd een volledige vervangingsbestelling plus de herinstallatiewerkzaamheden kost. Programmeer eerst NFC-tags, voer de praktijkproef uit en vergrendel daarna.

 

Het verifiëren van de chip is wat de factuur zegt

 

 

Chipauthenticiteit is geen paranoïde zorg in deze categorie, het is een routinematig inkomend-inspectie-item, en het hoort in dezelfde QC-stap als elke andere controle die u uitvoert voordat u NFC-tags in productiehoeveelheden programmeert. De NTAG-, MIFARE-, Ultralight- en ICODE-families van NXP dragen elk een op ECC-gebaseerde originaliteitshandtekening geschreven bij de chipproductie, 32 bytes op NTAG21x-onderdelen, die kunnen worden teruggelezen en geverifieerd aan de hand van de openbare sleutel van de fabrikant. Een tag die zich perfect gedraagt, kan nog steeds niet door deze controle heen komen.

 

Dit gebeurt meer dan de markt toegeeft. Ingenieurs die NTAG21x-tags kopen via algemene detailhandelskanalen hebben aan de eigen gemeenschap van de fabrikant gerapporteerd dat samples precies functioneren zoals gespecificeerd, inclusief counter mirroring, maar toch rapporteren als kloonsilicium onder originaliteitsverificatie, en het gepubliceerde antwoord van NXP is dat dergelijke onderdelen niet worden ondersteund en ongeschikt zijn voor veilig gebruik omdat de IC zelf mogelijk kwetsbaar is (NXP-gemeenschap).

 

De operationele consequentie is beperkter dan mensen denken, en het is de moeite waard om deze nauwkeurig te beschrijven. Als uw toepassing een marketingomleiding is, zal een kloonchip u voldoende van dienst zijn en het maakt u misschien niet uit. Als uw aanvraag authenticatie, manipulatiebewijs of een claim tegen -namaak tegen uw eigen klant omvat, maakt een niet-verifieerbare chip het hele uitgangspunt ongeldig, en geen enkele hoeveelheid correcte codering compenseert dit. De verificatie duurt enkele seconden per monster met een reader-app, en hoort thuis in uw inkomende kwaliteitscontroleprocedure in plaats van in een post-mortem. Gerelateerde lectuur voor iedereen wiens schrijven voltooid is, maar wiens lezer zwijgt:waarom een ​​gekloonde sticker goed leest en nog steeds faalt bij de deur.

 

De klassieke MIFARE-beveiligingsvraag, eerlijk herhaald

 

Iedereen die vandaag de dag MIFARE Classic specificeert zou moeten werken vanuit de huidige onderzoekspositie in plaats van de reputatie die het platform tien jaar geleden had.

 

In 2024 versloeg een studie van de FM11RF08S, een MIFARE Classic-compatibele chip die in 2020 werd uitgebracht met tegenmaatregelen die specifiek zijn ontworpen om alle bekende aanvallen met alleen kaarten te weerstaan, deze tegenmaatregelen en bracht daarbij een hardware-achterdeur aan het licht. Dankzij de achterdeur kan elke partij die hiervan op de hoogte is elke door de gebruiker-gedefinieerde sleutel op de kaart binnen enkele minuten na fysieke toegang in gevaar brengen, en dit geldt zelfs als de sleutels volledig per kaart zijn gediversifieerd (Cryptologie ePrint-archief). Gerelateerde achterdeursleutels werden geïdentificeerd in een bredere reeks onderdelen, waaronder eerdere Fudan-generaties en specifieke NXP- en Infineon-apparaten.

 

Lees dat aandachtig voordat u er de verkeerde conclusie uit trekt. Dit is niet het argument dat iedereen die MIFARE Classic gebruikt morgen aan de kaak wordt gesteld, en wij presenteren dit ook niet als argument. Miljoenen Classic-inloggegevens werken in omgevingen met lage- risico's, waarbij het klonen van een kaart een aanvaller toegang geeft tot een kluisje in de sportschool. Het is een argument dat de term 'veilig' nergens in een specificatiedocument naast deze chipfamilie mag voorkomen, en dat iedereen die op het punt staat NFC-tags te programmeren voor hotelkamers, kantoortoegang of contante betalingen op klassiek silicium een ​​migratie naar een op AES-gebaseerd onderdeel in dezelfde budgetcyclus moet inpassen.

 

NFC-tags in bulk programmeren: wat verandert er boven duizend eenheden

 

Alles wat tot nu toe is beschreven, schaalt slecht. Een telefoonapp schrijft één tag tegelijk zonder batchrecord, zonder verificatiepas en zonder manier om achteraf te bewijzen welke URL naar welke fysieke eenheid is gegaan. Er zijn drie niveaus voor het bulksgewijs programmeren van NFC-tags, en de sprong daartussen is eerder operationeel dan technisch.

 

Het eerste niveau bestaat uit een telefoon en een app, geschikt voor ongeveer honderd eenheden, geschikt voor prototypes en interne pilots.

 

Op het tweede niveau komen de meeste interne -teams terecht: je programmeert NFC-tags met een reader-writer op een desktop, aangestuurd door een batchbestand, meestal via een USB-encoder in de ACR12xx- of uTrust-klasse. Het werkt goed totdat de chip verandert. De veelgebruikte open-source batchtool op dit gebied richt zich bijvoorbeeld specifiek op de ACR122 en codeert alleen MIFARE Ultralight en Ultralight C, wat Type 2-onderdelen zijn. Als u dat project naar een Type 4-chip verplaatst, betekent dit dat u de tooling opnieuw moet opbouwen in plaats van een configuratiebestand te bewerken. Als u nog steeds hardware voor dit niveau kiest, kunnen onzeUSB- en desktop-NFC-lezer-reeks schrijversomvat de lezermodellen die deze toolchasins verwachten.

 

Industriepraktijk voor het derde niveau is pre-codering-tijdens de productie, en dit is het niveau waarvan de meeste kopers niet weten dat het bestaat. Op onze lijnen in een fabriek van 3.600 m² vindt de codering plaats tussen het bonden van de chips en de eindassemblage, op apparatuur die elke tag in positie indexeert, de record schrijft en deze terugleest voordat de tag verder gaat. De verificatiepas is het hele punt. Een tag die niet kan worden teruggelezen, wordt in de regel afgewezen- in plaats van ontdekt door een klant in het veld, en de batch vertrekt met een toewijzingsbestand dat elke UID of TID koppelt aan de exacte inhoud die ernaar is geschreven, wat uw CMS- of analyseplatform op de eerste dag nodig heeft. De geautomatiseerde bindingscapaciteit over vijf productielijnen bedraagt ​​meer dan 100.000 chips per dag, dus codering vormt geen beperking voor de doorlooptijd.

 

Wat die beschrijving bewust weglaat, is de acceptatiedrempel. Lees{1}}terugverificatie is een pass/fail-poort, maar het percentage mislukkingen dat u contractueel moet accepteren, verschilt per chipfamilie, vormfactor en of de tag daarna wordt gelamineerd; een anti-metalen sticker en een PVC-kaart gedragen zich niet hetzelfde op dezelfde lijn. Dat getal hoort thuis in een citaat bij je specifieke build, niet in een artikel, en het is het eerste dat we instellen als een nieuw programma start.

 

Waar we onze eigen capaciteitsgrens trekken, is het de moeite waard om duidelijk te vermelden, omdat dit de onderdelen zijn die leveranciers meestal vervagen. We zullen NFC-tags vooraf- programmeren met uw URL-sjabloon, serialiseren per eenheid, elke tag verifiëren en het toewijzingsbestand leveren. Wij zorgen voor de AES-sleutels die u verstrekt. We zullen uw productiesleutels niet bewaren, we zullen uw validatie-backend niet beheren en we zullen u niet vertellen dat een fabriek een beveiligingsontwerp van een applicatie-laag correct kan maken. Dat deel is van u, en elke leverancier die het tegendeel beweert, verkoopt u een risico-overdracht die niet bestaat.

 

Negen vragen die moeten worden opgelost vóór de coderingsrun

 

Voer dit uit vóór de inkooporder, niet nadat de monsters zijn aangekomen. Elk item heeft ten minste één project beëindigd dat we moesten redden.

 

#	Vraag	Waarom het de chip beslist
1	Zullen iPhones op deze tags tikken?	Hiermee wordt MIFARE Classic volledig buiten beschouwing gelaten
2	Wat is de volledige URL-lengte, inclusief toekomstige parameters?	Stelt de vloer in op NTAG213, 215 of 216
3	Is één record voldoende, of heeft u ook een tekstrecord of een app-record nodig?	Extra records verbruiken hetzelfde geheugenbudget
4	Zal de bestemming veranderen tijdens de levensduur van de tag?	Bepaalt of vergrendeling ooit acceptabel is
5	Maakt de applicatie een authenticiteitsclaim tegenover eindgebruikers?	Duwt je naar NTAG 424 DNA of DESFire
6	Wie houdt en roteert de AES-sleutels?	Moet worden toegewezen voordat een sleutel wordt gewijzigd
7	Wat is het acceptatiecriterium voor een geleverde partij?	Bepaalt of terugleesverificatie contractueel is
8	Heeft u een UID-naar-contenttoewijzingsbestand nodig?	Moet vóór de run worden opgegeven, niet daarna aangevraagd
9	Maakt verificatie van de handtekening op originaliteit deel uit van inkomende kwaliteitscontrole?	Bepaalt of chipsourcing controleerbaar is

 

Teams die alle negen kunnen beantwoorden, krijgen doorgaans bij de eerste poging een schone productierun. Teams die er zes van de negen kunnen beantwoorden, ontdekken de resterende drie meestal op de dure manier.

 

De negen vragen zijn de generieke versie. Degene waar we feitelijk mee werken voegt een tiende kolom toe, het antwoord dat juist is voor uw build in plaats van in het algemeen, en die kolom hangt af van dingen die dit artikel niet kan zien: uw handsetmix, uw lezersbestand, uw lamineerproces en of serialisatie opeenvolgend of willekeurig moet zijn. Stuur ons de eerste negen antwoorden en wij sturen de geannoteerde versie volgens uw specificatie terug.

 

Waar dit een koper achterlaat

 

Er is geen algemene procedure voor het programmeren van NFC-tags, alleen een procedure per chip, per platform, per volume. Kies eerst de chip tegen het geheugenplafond en de iPhone-vraag. Behandel opmaak, payload en configuratie als drie afzonderlijke poorten. Sluit nooit af vóór een veldproef. Controleer de originaliteit van binnenkomende monsters. Boven de duizend eenheden, stop met denken aan apps en begin na te denken over verificatie en traceerbaarheid.

 

Als er al een specificatie is opgesteld, beoordelen we deze graag aan de hand van de bovenstaande chipbeperkingen en markeren we alles dat de productie niet zal overleven. Er zijn gratis monsters beschikbaar om te testen op uw daadwerkelijke lezers en handsets. Je kunt ook starten vanaf deNFC-tagformaten die we intern -voorprogrammeren en verifiërenals de chipbeslissing nog open is, ofstuur de URL-structuur en het doelvolume voor een coderingsbeoordelingals het al opgelost is.

 

Veelgestelde vragen